Check for API/behaviour changes in Android 13 that could affect Briar
- https://developer.android.com/about/versions/13/behavior-changes-13
- https://blog.esper.io/android-13-deep-dive/
- https://commonsware.com/blog/2022/02/12/random-musings-android-13-dp1.html
- https://commonsware.com/blog/2022/03/19/random-musings-android-13-dp2.html
Changes that may affect us:
- Low power standby is a new power saving mode (apparently distinct from doze, light doze and power save mode) in which apps with foreground services lose network access and their wake locks are ignored. It's not clear whether doze exemption affects this mode. We should look for ADB commands that can be used to test this mode
- Light idle mode has also been added to the PowerManager API, although this may just be exposing the "light doze" mode that was added in Android 7
- Apps are placed in the "restricted" app standby bucket if they "drain a significant amount of device battery during a 24-hour period". This is likely to apply to Briar and Briar Mailbox. Apps are also placed in the "restricted" bucket if the user doesn't interact with them for 8 days. This is very likely to apply to Briar Mailbox and may also apply to Briar. Running a foreground service isn't enough to meet definition of "interaction" being used here. The docs for app standby buckets say "Apps that are on the Doze exemption list are exempted from the App Standby Bucket-based restrictions." We should test whether this remains true for the new restrictions. We should also add code to log which bucket we're in periodically
- Apps need to ask permission to show notifications - if the app doesn't target API 33 then the permission prompt will be shown automatically when the notification channels are created, which in Briar's case happens after signing in
- The new foreground services task manager enables the user to stop foreground services. Stopping an app in this way is roughly equivalent to force-stopping the app, but just different enough to make sure we'll have to test both workflows. Related to #2010
- New rules for intent filters could affect our use of intents to open other apps (such as manufacturer-specific power management apps). These rules apply if the app receiving the intent targets API 33 or higher, so it could take a while for any effects to be noticeable Article: https://medium.com/androiddevelopers/making-sense-of-intent-filters-in-android-13-8f6656903dde
- We should check whether the
RECEIVER_NOT_EXPORTED
flag is relevant to us (all our BroadcastReceivers are used for receiving system broadcasts) -
NEARBY_WIFI_DEVICES
permission - this replacesACCESS_FINE_LOCATION
for some wifi APIs. We should use the new permission and find out whether location services still need to be enabled for these APIs to work - If the user places an app in the "restricted" state for background battery usage (which AFAICT is unrelated to the "restricted" app standby bucket) then the app can't run foreground services, schedule alarms or run jobs. If the app targets API 33 then it can't receive
ACTION_BOOT_COMPLETED
broadcasts either, which we use for the sign-in reminder -
System notification for long-running foreground services ("APP is running in the background for a long time. Tap to review") - as CommonsWare says, the obvious response from developers is to add
FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK
orFOREGROUND_SERVICE_TYPE_LOCATION
, and the obvious response from Google is to restrict those flags in the next update - System notification for excessive background battery usage - the docs say this notification will be shown after our foreground service finishes, ie after the user signs out, which may cause confusion
- I'm sure TARE will produce great value for users and won't just be the equivalent of adding a dice roll to every attempt to queue a job or schedule an alarm. We should keep it in mind when debugging alarm issues
- Apps can release unused permissions - this looks useful for privacy-conscious users but some care will be needed to integrate this into our app lifecycle, as the system kills the app asynchronously at some point after the API is called
- There's a new AndroidX API for implementing in-app language pickers, which is great. The user can also pick a per-app language through the system settings app, in which case "The list of available languages might not reflect the languages that your app supports". This will need testing
- There's a new API for opting out of screenshots in the recent apps list without preventing the user from taking screenshots. This may be useful if it doesn't open some other horrendous information leak
- SystemClock#currentNetworkTimeClock() may be useful for diagnosing whether clock sync issues are due to misconfiguration or NTP tampering
- Apps with the
ACCESS_FINE_LOCATION
permission are exempt from most of the power management changes in Android 13, as are media players that are actively playing media. Perhaps Google thinks media players and navigation apps (or exercise trackers?) should be allowed to run in the background, which would be consistent with the apparent intent of previous loopholes