Android main module is starting twice due to configuration change

[timrid]

Describe the bug

I am currently working on an Android bleak PR. The BLE API slightly differs between different API levels so I tried to run the integration tests on different emulators with different API levels (31-36). I noticed, that the emulator on API level 35 and 36 are often failing or hanging completely, when running on Github Actions. Locally I could not reproduce the error. Here is an example of such an failing CI run. That uses system-images;android-36;default;x86_64 and I added a script to show more logcat output than usual, for example to see the ActivityTaskManager output.

I noticed, that on the API 35 and 36 emulators the onDestroy method is called when the CI run fails. The onDestroy call is followed by a second onCreate call. In the second onCreate call you can see D/MainActivity: Python already started in the logs. And then later you can see that my pytests are running twice. E.g. the line

I/python.stdout: platform android -- Python 3.13.9, pytest-9.0.3, pluggy-1.6.0 -- /system/bin/app_process64

is twice in the logs. So I guess that this is the cause of my error, that my test script is running twice in parallel.

But why is is the onDestroy is called in the first place? I guess it is because of the config change

04-24 14:21:10.895   668   697 I ActivityTaskManager: Config changes=80000000 {1.0 310mcc260mnc [en_US] ldltr sw411dp w411dp h731dp 420dpi nrml long port finger qwerty/v/v dpad/v winConfig={ mBounds=Rect(0, 0 - 1080, 1920) mAppBounds=Rect(0, 0 - 1080, 1920) mMaxBounds=Rect(0, 0 - 1080, 1920) mDisplayRotation=ROTATION_0 mWindowingMode=fullscreen mActivityType=undefined mAlwaysOnTop=undefined mRotation=ROTATION_0} as.2 s.22 fontWeightAdjustment=0}

that occurs after the first onCreate is called and so an app recreation is triggered. On the API level 31-34 this config change always occurs before my app is started an thus the app recreation is not triggered.

At first I thought that maybe only the emulator boot complete detection is wrong, but then I saw in the Android docs, that an app recreation can always happen and some of the recreations cannot be suppressed. So probably the handling of the Android app recreation is not correctly.

How to reproduce the bug

1. Fork my branch https://github.com/timrid/bleak/commits/android-35-and-36-bug and start the build_and_test.yml Github Actions run manually via workflow dispatch
2. Look at the CI output of the Android integration tests (3.13, 35) or Android integration tests (3.13, 36). Sometimes they fail with random errors or hang up completely. The runs using a API 31-34 emulator runs without problems.

Minimum example code

Screenshots

No response

Environment details

• Operating system and version: Ubuntu (Github Actions CI)
• Python version: 3.13
• Software versions:
  • Briefcase: 5610048a07ff79ebaf2048d28c7fdc9bda9b327c
  • Toga: 199b0fa751d944b9c83c5d29602c263a2fda3cd2
  • ...

Logs

job-logs.txt

Additional context

When looking at the onCreate of the briefcase-android-gradle-template , I noticed that this uses the Activity.onCreate to starte the Python interpreter and start the main script and not the Application.onCreate as suggested in the chaquopy docs. Maybe this is part of the reason.

[mhsmith]

I noticed that this uses the Activity.onCreate to starte the Python interpreter and start the main script and not the Application.onCreate

This is necessary for Toga, because the main script needs an Activity in order to create the app's UI.

We had some previous reports that you could run the main script multiple times in a process if the the activity was closed and then reopened. However, this became a lot less likely to happen on more recent versions of Android (beeware/toga#1803 (comment)).

For your tests, you can probably work around it by using a flag variable in your Python code to track of whether the tests have already been started, and make sure they aren't started a second time. However, for a normal app with a user interface it might not be so easy, because the UI actually needs to be recreated when the activity restarts. So I'll leave this issue open until we've had a chance to investigate some more.