Skip to content

[Android] Adding debug logs - #5461

Draft
IvanBM18 wants to merge 26 commits into
masterfrom
feature/android-debug-logs
Draft

[Android] Adding debug logs#5461
IvanBM18 wants to merge 26 commits into
masterfrom
feature/android-debug-logs

Conversation

@IvanBM18

@IvanBM18 IvanBM18 commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

Overview

Adding debug level logs to follow android fuzzing sessions and interactions.

Changes

Basically changed the debug level for a ton of logs in android related functionality, i focused specifically at:

  • testcase_manager.py
  • adb.py
  • fetch_artifact.py

Note

This PR is dependent to 2 PRs coming from 2 different PR stacks:

@IvanBM18
IvanBM18 force-pushed the feature/android-debug-logs branch from b907e82 to 81e40db Compare September 8, 2026 17:44
IvanBM18 added a commit that referenced this pull request Sep 11, 2026
Bug: b/553141628

## Overview
Since Android API level 30 (and apps targeting Android 11+), apps have
scoped storage access. Previously, bad build checks for Android did not
verify whether the application process actually survived startup because
`am start` returns 0 even if the process dies immediately.

This PR enhances `check_for_bad_build()` in `testcase_manager.py` by
ensuring command line files are written prior to execution and flipping
a conditional so in the bad build check the android specific validation
proceeds other validations.

The later was required because thanks to [this
PR](733e28f?diff=unified)
we added the possibility to check for false positives, but this added a
problem in which valid builds were incorrectly flagged as crashes, so by
flipping the conditional we fix this.

## Changes
- `src/clusterfuzz/_internal/bot/testcase_manager.py`: Updated
`check_for_bad_build()` to pass `write_command_line_file=True` and
verify target application process presence on Android post-launch.

## Tests performed
> Basically the same as the parent PR 
- Tested them in swarming:
https://chrome-swarming.appspot.com/task?id=7a8188fe65a42510
- Tested them locally using an avd device against an invalid apk, that
is the previous iteration of our chrome public apk, the apk returned the
following:
```
reason=2 (SIGNALED) subreason=0 (UNKNOWN) status=9
```
When this happen now CF correctly determines that the app crashed due to
runtime issues not related to memory errors.

## PR stack
- `master`
  - **#PR 2.1a** `feature/android-exit-code-constants`
  - **#PR 2.1b** `feature/android-exit-code-core`
  - **#PR 2.2** `feature/android-exit-code-process-handler`
  - **#PR 2.3** `feature/android-bad-build-check` 👈
  
 ## Note:
  Adding additional debug logs in this other PR:
  - #5461
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant