IssueTracker

This form is only for reporting platform issues and requests related to the Android 16 Developer Preview or Beta. Only report issues that are regressions from the behavior in Android 15. For all other issues that are also reproducible on other versions of Android, please report those issues in the AOSP issue tracker at https://goo.gl/TbMiIO.

If the issue is caused by an app and not a platform issue, we will do our best to route the issue to the app developer. However, note that it is up to the app developer to actually address reported issues.

Before logging your issue, check to see whether it is a known issue described in the current release notes at:

https://developer.android.com/about/versions/16/release-notes

or has already been reported at:

https://bit.ly/4fFfuE2

If the issue has already been reported, you can "star" or comment on the existing report if it corresponds to the issue you are seeing.

To expedite resolution of your issue, please provide as much relevant and specific information as possible. This will probably require some work from you. Most reports should include at least the following:

    * Are you an Android developer?" (Y/N) Y

    * Which Android Developer Preview build are you using? See Settings > About phone > Build number (for example AP3A.241105.008). sdk_gphone64_arm64-userdebug Baklava BP22.250103.008 12932282 dev-keys
   
    * Is this a regression from Android 15 to 16? Yes

    * What device are you using? (for example, Android Emulator, GSI, Pixel 9) Android Emulator

    * What are the steps to reproduce the problem? (Please provide the minimal reproducible test case.)

Minimal repro at https://github.com/bubenheimer/baklavafgserviceissues

1. Build & install app
2. Run app, preferably starting directly on device, not via Android Studio Run button, to avoid potential Studio interference
3. Grant location permissions when prompted
4. Observe that app has 2 processes. Initial process displays UI, location foreground service runs in separate ":ext" process. This can be viewed via Android Studio "Device Explorer" window, adb shell ps command, or similar tools.
5. For easier reproducing, go to the device Home screen, to move initial process to the background. Note that ":ext" process continues running in foreground due to hosting a foreground service; this process logs to the console every 5 seconds.
6. Kill ":ext" process. (DO NOT FORCE STOP!) This can be done via Android Studio Device Explorer window, via adb shell kill command, or similar tools. This action simulates the Android Low Memory Killer (LMK) temporarily yanking the process.
7. Wait for ":ext" process to automatically re-create (typically within a few seconds).
8. Repeat steps 6 and 7 until process no longer re-creates.

    * Issue Category e.g. Framework (platform), NDK (platform), Hardware (CPU, GPU, Sensor, Camera), ART (platform), Runtime Permissions etc

Framework (platform)

    * What was the expected result?

":ext" process recreates indefinitely after being killed, within a short timeframe. This is the behavior observed on all prior Android versions, including Android 35, where I tested this behavior extensively.

Notably, on Android 35, there are occasional outliers with a distinct recreation delay of slightly more than 4 minutes. From my perspective this should not happen, either, as a sticky foreground service is expected to essentially be always available; extended downtime is not really tolerable for my app. These outliers also make it much harder & time-consuming to robustly pinpoint foreground service issues.

However, I have always seen it come back after no more than about 4 minutes on Android 35. This is not the case on Baklava Beta 1, where the process does not always recreate, even after hours of waiting.

    * Can you provide the API document where this expected behavior is explained?

Standard behavior of foreground services started with "Service.START_STICKY"

    * What was the actual result?

Estimated average frequency of total process loss on Baklava was about 1 loss in 5 to 10 kills.

    * Relevant logcat output.

Nothing relevant here.

   * Link to captured Android bug report (shared privately in Drive.)

   * Optional: Link to any screenshot(s) that demonstrate the issue (shared privately in Drive.)

To avoid the possibility of sharing private information, please share bugreports and screenshots from Google Drive. Share files with android-bugreport@google.com and include only Google drive links in your bug. Please note, bug report attachments should not be included directly in issue reports.

Disclaimer:
Please note, by submitting this bug report, you acknowledge that Google may use information included in the bug report to diagnose technical issues and to improve our products and services, in accordance with our Privacy Policy (https://policies.google.com/privacy), and you agree that we may share it with engineering partners potentially impacted by your issue.

Bug reports include personal information logged on your device or by apps, such as:
File names
Installed apps and usage
Email addresses of the profiles on the device
Device identifiers, such as phone number
Web history information, including URLs / URIs
Location information, including limited location history
Network information, such as IP/SSID/MAC addresses and saved or scanned APNs
System or device information, such as memory and processes