Is Your App Ready for Android Marshmallow?
With the announcement that Android Marshmallow has started to roll out to a wide range of devices, it’s time to start thinking about the impact of the release and to start planning integration of new features such as Fingerprint Authentication, App Linking, Voice Interactions, and Direct Share. However, this release requires much more than a quick flip of the Target & Compile SDK to API 23, as there are several important changes that you should start thinking about right now to have your app fully prepared for Android Marshmallow.
The most fundamental change in Android Marshmallow is the introduction of Runtime Permissions. I previously covered the runtime permissions workflow, showing you how to ask your users for permission to use several common APIs such as Camera, Location, and Storage. This is an awesome new feature for users, but it’s important to note that runtime permissions only impact devices running Android Marshmallow, and your app will still function the same on older versions of Android. Additionally, runtime permissions are only required if you change your Target framework and Target Android version in your Android project’s properties to API 23 or higher. This means if you aren’t ready to implement the necessary changes for runtime permissions in your app, or you don’t need to take advantage of any new features in Android Marshmallow, then you can keep compiling and targeting against API 22 until you are ready.
Doze & App Standby
In its quest for power efficiency, Android Marshmallow is introducing new system-level functionalities to more aggressively control apps that exhibit energy consuming patterns. Dubbed Doze and App Standby, both features can have an impact on your app behavior, depending on system conditions.
Doze will detect when a device is left idle and stationary (using accelerometers, gyroscope, and other sensors) and automatically throttle down power usage for a longer time period. The idea is that a device left alone in the morning should have roughly the same battery level when you grab it at the end of the day.
App Standby will work by detecting apps that the user hasn’t used in a long time, either directly (for instance opening the app from the launch screen) or indirectly (the app triggers a notification). Based on those usage statistics, App Standby can choose to voluntarily block your application so that it doesn’t impact the system. This allows better battery life for people who tend to install a lot of applications that they then forget to uninstall when they’re not needed anymore.
In both case, the effects on your app are the same: network will be forcibly shut down to cut power on the device radios and most form of device wakeups (alarms, wakelocks, sync services, …) will be prohibited/ignored while any of those feature are active.
While this aspect of Marshmallow doesn’t really introduce new API changes, it’s something to keep in mind since it could negatively affect your application, especially if it needs reliably timed operations or if network-related method calls are insufficiently protected against exceptions that will be thrown when the network is de-activated.
Refer to the Android documentation for more details on how you can test the impact of Doze and App Standby on your apps.
Android always had a backup facility to save key aspects of an app (e.g. user preferences). In Marshmallow, this feature is greatly extended to save a larger chunk of an app’s data directly to the user’s Google Drive instance. The data will then be restored when the user upgrades or changes devices, providing a more seamless experience.
This feature is enabled automatically as long as the user is running Marshmallow and no other work is needed by the developer. The only thing you may need to consider is if any data produced by your app shouldn’t be backed up to the cloud.
You can find more information on this dedicated guide.
Google Play services
If your application is using the Google Play services SDK, it’s now required to update to the latest version, 8.1, which is compatible with the new runtime permissions introduced in Android 6.0 Marshmallow. The release candidate of the SDK is available directly from NuGet for now. To learn more about these changes, be sure to check out the Android Developer blog post.
If you’re developing an Android application utilizing Xamarin.Forms and want to take advantage of Android Marshmallow features such as Auto Backup, you may want to think about re-compiling against API 23. Be aware that the same considerations around runtime permissions are required and can be controlled by adding the necessary permission request code to your MainActivity. If your application is using the Xamarin.Forms Maps NuGet, you should continue to compile against API 22 until the Xamarin.Forms.Maps NuGet has official support for the latest Google Play services SDK.
Configuring Your App for API 23
To target your Android application for Android 6.0 Marshmallow, ensure that you have the latest stable release and have updated your Android SDKs and Build Tools. In your project options you’ll want to set your Target framework and Target Android version to API 23. In Xamarin Studio, the Target Android version is found under Android Application:
Target framework is found under General:
In Visual Studio all of the settings are found under Android Application.
To learn more about Android Marshmallow’s features and how to get started, be sure to read through our full Introduction to Android Marshmallow documentation and browse through the sample projects to test out these new features.