[Android] Integrate exit code handling into process_handler

[IvanBM18]

Bug: b/553141628

Overview

Since Android API level 30 (and apps targeting Android 11+), apps have scoped storage access. am start process execution does not report exit codes on activity crashes, returning 0 even when native crashes occur.

This PR integrates Android activity crash detection and reboot tracking into process_handler.run_process(), ensuring process return codes accurately reflect native crashes (e.g. SIGSEGV, SIGABRT) or device reboots at test case executions. We also correct an intermittent issue in which the time since the last reboot vs time since activity launched was calculated incorrectly.

Changes

• src/clusterfuzz/_internal/system/process_handler.py: Integrated activity_crashed_by_package() check and reboot validation in run_process() for Android.
• src/clusterfuzz/_internal/tests/core/system/process_handler_test.py: Added unit tests for Android activity crash and clean exit handling in run_process().

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

[Xeicker]

I don't quite get why it is an issue that the uptime is calculated incorrectly and how it is related to the returning codes issue.
Not that it shouldn't be fixed, just curious why to integrate it in the stacked PRs

[Xeicker]

nit: I would use exit reason low memory. I'd consider that a bit more consistent

[IvanBM18]

Currently when memory on the device is low, CF performs a reset on the device and then continues the execution without marking the test case or the bad build check as a crash, returning a non 0 exit reason here would change that, so i don't think this one is feasable.

[dylanjew]

LGTM

[IvanBM18]

I don't quite get why it is an issue that the uptime is calculated incorrectly and how it is related to the returning codes issue. Not that it shouldn't be fixed, just curious why to integrate it in the stacked PRs

Answering your 'uptime calculation question' When testing this changes i performed quite a ton of tests, and i saw that intermittently CF marked the test case as a failure because of this, even though i was seeing the test case execution directly on the avd's screen, and since the fix was a small pretty straight forward one i figured that it might fit into this small pr of changes in this stack