Developing Mobile Applications for Android 13

The moment an Android user is informed of an update, the user would upgrade the OS. But even though the device is upgraded, the applications installed in the device might not be developed considering the latest version of Android. This might raise operational challenges when the application is used with Android 13. Thus, it is essential to make some modifications to the applications when used with Android 13. An application developer must understand how the interaction between an application and mobile OD is affected with Android 13.

Some tweaks might be required in the application if it must perform well with Android. In this article, we will discuss how Android 13 interacts with a mobile application and understand its limitations. We will further provide some guidance on how you can create an application that works well with an Android 13 device. A few modifications are recommended in applications to support Android 13.

How Mobile Applications work on Android 13 devices

In the Android 13 device, several changes have been made that can affect the way mobile applications work on Android devices. Here are some ways a mobile application interacts with Android 13 differently than earlier versions:

• Foreground Services (FGS) Task Manager: On Android 13, the notification drawer contains the list of active foreground services with stop buttons. When the stop button next to an app is pressed, it is not just the foreground service, but the entire application stops.
• Improved pre-fetch job handling using JobScheduler: In Android 13, determination of the next time app launch and uses the estimation to run prefetch job. App should use prefetch jobs

    (JobInfo.Builder.setPrefetch())

for any work they want to be done prior to the next app launch.

• Battery Resource Utilization: On an Android 13 device, an app must consider certain limitations on the background battery usage. There are 3 modes in which an application may operate based on how it uses its battery. These include:
  • Unrestricted: In this mode, more battery is consumed when background work is allowed
  • Optimized: This is the default mode that optimizes the app’s ability to perform background work depending on how a user interacts with the app
  • Restricted: In this mode, priority is given to the device battery and the background work is limited. An application is put in a restricted bucket in the following cases:
    • When the user is not interacting with an app for 8 days. However, it is considered “used” if another app is bound to its services.
    • When an app invokes many broadcasts or bindings within 24 hours
    • When the app is draining a significant amount of battery in 24 hours, this is based on the capacity of RAM in the device.

To put an app into the restricted bucket, the following code is generated:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Prevent background usage adb shell cmd appops set PACKAGE_NAME RUN_ANY_IN_BACKGROUND deny

Exemptions to battery-saving measures:

Apps Exempted: Certain Android applications are exempted from battery-preserving measures. These include:

• System apps and system-bound apps
• Companion device apps
• Apps running on a device in Demo Mode
• Device owner apps
• Profile owner apps
• Persistent apps
• VPN apps
• Apps that have the ROLE_DIALER role
• Apps that the user has explicitly designated to provide “unrestricted” functionality in system settings

Situations Exempted: If the app itself is not exempted from battery-saving measures, certain situations can exempt an app from entering the “restricted” App Standby Bucket. This allows the app to bypass the 8-day inactivity trigger. These are:

• The app has active widgets
• The app is granted at least one of the following permissions:
  • SCHEDULE_EXACT_ALARM
  • ACCESS_BACKGROUND_LOCATION

Furthermore, in the following cases, the app exits the restricted bucket:

• The user taps on the app notification but does not swipe it away without interacting with it
• The User interacts with the app widget
• The App is visible in PIP (picture in picture) mode
• The app is one of the active apps on the screen
• The foreground service is affected by the user in your app by pressing a media button
• The user connects to your app while interacting with Android Automotive OS, where your app uses either a foreground service or CONNECTION_TYPE_PROJECTION

The following situations exempt an app from most battery-preserving measures in Android 13:

• Has an in-progress, active MediaSession
• Granted at least one of the following permissions:
  • ACCESS_FINE_LOCATION
  • CAMERA
  • RECORD_AUDIO

Exemption in notifications: However, a notification is still sent to the user for any application that runs its foreground service for at least 20 hours in the 24-hour window except in the following cases:

• Foreground service type is either FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK or FOREGROUND_SERVICE_TYPE_LOCATION
• The notification associated with the foreground service is visible to the user and the user has not swiped away

Runtime permission for notifications: To help users to focus on the most important notifications, Android 13 has introduced a new POST_NOTIFICATIONS permission but the notifications related to media sessions are exempted.

To learn more about Android 13, check out this recent blog: Android 13 Developer Preview: New Features and APIs

Building app for Android 13

Let’s explore how to modify your mobile application to support Android 13. The changes you need to make include:

New runtime permission for nearby Wi-Fi devices: If an app running on Android 13 calls WI-FI APIs without proper permissions, a SecurityException can pop-up on the console, or the app could crash. This happens because of NEARBY_WIFI_DEVICES runtime permission that has been introduced in Android 13 as a part of NEARBY_DEVICE permission group. In earlier Android versions, you just needed to declare ACCESS_FINE_LOCATION permission. But with this new permission routine, some use cases must follow the new procedure for permissions. These are:

• Find or connect to a nearby device such as printers or casting media
• Connecting to known SSID, such as car or smart home device.
• Staring local-only hotspot
• Range to nearby WI-FI aware device

The use of body sensors in the background requires a new permission: From API 20, BODY_SENSOR permission was introduced for accessing heart rate, temperature, and blood oxygen percentage. But if your app is targeting Android 13, it also needs to declare BODY_SENSOR_BACKGROUND permission in addition to the BODY_SENSOR permission. Android 13 has also introduced the concept of “while in use” with a similar access model.

Intent filters block non-matching intents: When your app sends an intent to an exported component of another app that targets Android 13 or higher, the intent is delivered only when it matches with the <intent-filter> element in the receiving app. All non-matching intents are blocked by the system, except the following:

• Intents sent to other apps’ components that don’t declare any intent filters
• Intents sent to other components in your app
• Intents sent from the system
• Intents sent from a user with root-level privileges
• Granular Media permissions

Instead of using READ_EXTERNAL_STORAGE, an app can now use specific permissions to request access to specific types of media.

Please follow these migration steps for your app if you are targeting Android 13

<manifest ...>

    <!-- App targets Android 13.  Declare any of below required permission. -->

    <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />

    <uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />

    <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />

    <!-- Required to maintain app compatibility. -->

    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"

                     android:maxSdkVersion="32" />

</manifest>

Achieving Success with Mobile Apps on Android 13

Mobile applications when run on Android 13 decide needs some modifications to be able to work productively. Without these considerations, certain applications might act differently from user expectations. Thus, it is recommended that application developers make the necessary tweaks to make their applications aligned with Android 13 changes.

Apexon is committed to building apps of the highest quality that are both beautiful to look at and easy to use. We help enterprises deliver differentiated services, reduce costs, and improve efficiencies through data-infused end-to-end custom application development services aligned closely with your product/service lifecycle

To learn more about Android 13 app development, check out Apexon’s Custom Application Development services or get in touch directly using the form below.