Five changes in Android 12 dedicated device fleets need to prepare for
The stable version of Android 12 is available now. Staying true to the personalization experience that Android has always offered — allowing you to choose the right device and service — Android 12 comes with a major UI transformation. Along with the major interface changes, there are some lesser-known improvements that the developers need to be aware of. With a ton of exciting new features to unpack, I’m sure Android developers can’t wait to get their hands dirty.
If you’re building a dedicated device fleet on Android 12, you want to start with the Android 12 SDK. Since this SDK is compatible with most older versions, developers can focus on targeting API level 31 while developing their apps. It’s also recommended that you use Android Studio Arctic Fox | 2020.3.1 or higher.
By targeting Android 12 and the latest Android API level (31), you can ensure your fleet devices have access to the latest platform features — and are ready for changes that could have impacts on your apps and workflows down the road. Here, we have a checklist of some important developer-facing features of Android 12 that you need to be ready for.
- Microphone and camera toggles
Android 12 introduces a new feature to quickly turn off the microphone and camera. This toggle will allow you to enable and disable the microphone and camera for all apps on the device. The device user can access this feature from the quick settings interface.
Suppose you have the microphone and camera toggle button set to off, but your application requires you to use the microphone or the camera. The system will prompt you that the button is set to OFF.
This privacy feature gives users more control over when apps can see or hear them but could be enabled or disabled inadvertently.
- Hide application overlay windows
The applications that have the SYSTEM_ALERT_WINDOW permissions, can hide the overlay windows displayed by the application. With this permission, you can hide all the windows displayed when your application is being used. You might use this permission for tasks like the display of transaction confirmation flows.
In your application, this is useful for our digital signage and kiosk use cases where you don’t want something— like a system update window— showing up while the user is interacting with the display.
- Device properties attestation
In Android 9, device policy owners (DPOs) were used to verify if security keys and certificates were generated on the device, by the device, using hardware identifiers. When the user generates a new key, all the Android 12 applications can now verify the device information — brand, device, model, product, and manufacturer. This device’s properties must be listed in the attestation certificate. Any app can verify the authenticity of a security key, making it easy to create security redundancies on end devices.
- Bandwidth estimation improvements
In Android 12, the bandwidth estimation values returned for both cellular and Wi-Fi connectivity now represent the user’s all-time weighted average productivity — Wi-Fi SSID, network type, and signal level, across all applications on the device. You can benefit from the weighted average’s many advantages, such as a more accurate and realistic estimate of expected throughput.
This will allow you to better determine the network state of the devices and make your apps more intelligent when it comes to downloading content.
- Restrictive App Standby Buckets
This helps the system prioritize apps’ requests for resources based on how recently and how frequently the apps are used. In Android 12, a new App Standby Bucket named ‘restricted’ is being introduced. This restricted bucket will have the lowest priority and highest restrictions. This more aggressive bucket will free up more resources for your main application.
If the users display a higher level of engagement with the app and you use system resources responsibly, you can avoid your app being added to the “restricted” bucket and, if it does, check it still works as intended. Make sure the app you design has a launcher activity. This activity will help promote the app to the active bucket.
Here is a list of features that Google will not support in Android 12.
- Apps can’t close system dialogs: The intent to allow applications to close system dialogs will no longer be available from Android 12. When an application tries to invoke this action, apps targeting Android 12 will throw an exception. For apps targeting Android 11 and below, this intent does not exist and a Logcat will be generated.
- Bouncy Castle implementation removed: In the applications that use 512-bit key sizes, invalid key sizes with KeyGenerator, and initialize your Galois/Counter Mode (GCM) ciphers using a size other than 12 bytes; Google has removed many Bouncy Castle implementations.
- Root launcher activities are no longer finished on the Back press: Android 12 pushes the launcher activities and their related tasks back of the stack. In Android versions below 12, the launcher activities were handled in the back press.
Stay tuned for more information on how Esper plans to support Android 12 Snow Cone. In the meantime, enjoy reading our post on The Benefits of Android DevOps.