Developer Breakdown: What’s Inside the Android N Developer Preview?

We have had some time to play, experiment and experience the new features of Android N, based on the developer preview version.   In this post we are sharing our observations and experience with it.

Performance Improvements

Android N contains system behavior changes aimed at improving the battery life of devices, RAM usage and app performance. These changes can affect the availability of system resources and system notifications to your app.

What is Doze?

This is a brand new feature introduced in this latest version. Its main aim is to improve the battery life by deferring CPU and network related operations.   When a device is on battery power, and the screen has been off for a certain time, the device enters Doze and applies the first subset of restrictions: It shuts off app network access, and defers jobs and syncs. If the device is stationary for a certain time after entering Doze, the system applies the rest of the Doze restrictions to wakelock, alarms, GPS, and Wi-Fi scans.

Regardless of whether some or all Doze restrictions are being applied, the system wakes the device for brief maintenance windows, during which applications are allowed network access and can execute any deferred jobs/syncs.

Will existing applications using schedulers and alarms stop getting events in Doze state, and if yes, is there a workaround?

Doze can affect apps differently, depending on the capabilities they offer and the services they use. Many apps function normally across Doze cycles without modification. In some cases, you must optimize the way your app manages network, alarms, jobs, and syncs.

Doze is particularly likely to affect activities that alarms and timers manage, because alarms in Android 5.1 (API level 22) or lower do not fire when the system is in Doze. To help with scheduling alarms, Android 6.0 (API level 23) introduces two new AlarmManager methods: setAndAllowWhileIdle() and setExactAndAllowWhileIdle().With these methods, you can set alarms that will fire even if the device is in Doze.

What are the Background optimizations targeted for Android N?

For background optimization, Android N mainly removes implicit broadcast which helps in memory use and power consumption. It is necessary because implicit broadcast frequently starts apps that have registered to listen them in background.

It’s CONNECTIVITY_ACTION which the application registers to check the connectivity states which is more of a memory- and power-consuming task. Another is ACTION_NEW_PICTURE and ACTION_NEW_VIDEO broadcasts from other apps which are fired when the user takes a new photo or video, which wakes up all applications that are registered to listen. Android N targeted apps do not receive CONNECTIVITY_ACTION broadcasts, even if they have manifest entries to request notification of these events. Apps running in the foreground can still listen for CONNECTIVITY_CHANGE on their main thread if they request notification with a BroadcastReceiver. This applies to other implicit intents as well.

What if an application still uses these 3 implicit broadcasts?

If your app uses any of these intents, you should remove dependencies on them as soon as possible so that you can target Android N devices properly. The Android framework provides several solutions to mitigate the need for these implicit broadcasts or background services. For example, the JobScheduler API provides a robust mechanism to schedule network operations when specified conditions, such as connection to an unmetered network, are met.

How does an existing application behave when it is into Doze mode running on a real device with Android N?

One of our existing apps needs continuous access to GPS and network to function correctly. So, we have chosen it to test for doze-mode behavior.

Did the existing app function as per expectations?

No, Android N restricted GPS and network access of the app when in Doze mode. So the app did not function as expected. However, periodically, the system exited from Doze mode and provided a maintenance window and that allowed the app to use GPS and network access for that time.

How did we solve this issue?

The best way to deal with Doze mode is using the whitelisting feature provided by Android N developer preview, which provides partial exemption from Doze mode. An application which is whitelisted can use the network and keep wake lock during this mode and app standby. Other restrictions still apply to the application and there is an API provided to check for the whitelisting state of the app.

How do you use the whitelist feature?

Users can manually configure the whitelist in Settings > Battery > Battery Optimization. Alternatively, the system provides ways for apps to ask users to whitelist them.

Multi-Window Support

Android N introduced this feature to display more than one app at the same time. On handheld devices, two apps can run side-by-side or one-above-the-other in split-screen mode. On TV devices, apps can use picture-in-picture mode to continue video playback while users are interacting with another app.

Does the Multi Window feature have a separate lifecycle?

This doesn’t affect the actual activity life cycle, instead it keeps only one activity active at any given point of time and this will be most recent activity. This activity is considered topmost. All other activities are in the paused state, even if they are visible. However, the system gives these paused-but-visible activities higher priority than activities that are not visible. If the user interacts with one of the paused activities, that activity is resumed, and the previously topmost activity is paused. So this sums up with more onPause() method call when the application goes and comes back from Multi Window mode.

How is an application notified of a Multi Window event?

When the user puts an app into Multi Window mode, the system notifies the activity of a configuration change. Essentially, this change has the same activity-lifecycle implications as when the system notifies the app that the device has switched from portrait to landscape mode, except that the device dimensions are changed instead of just being swapped. The activity can handle the configuration change itself, or it can allow the system to destroy the activity and recreate it with the new dimensions.

How does an existing application behave in Multi Window mode running on a real device with Android N?

If we run the existing app and switch into the Multi Window mode then the system does not allow this app to fit into this mode and it automatically becomes full-screen or single window. To enable an existing app for Multi Window mode, first we need to modify the existing app’s configurations.

After enabling the app for Multi Window support mode, did it run as expected? How did the UI look into split mode?

If an app has support for Multi Window mode, then its screen automatically tries to shrink and fit into smaller window. If the app has responsive design, then it gets adjusted into split mode otherwise it gets distorted. In our case, the application was not designed to be responsive so it was distorted.

How did you solve this issue?

As part of resolution, the application has to design the layout for a smaller window or be much more responsive to fit into the Multi Window screen for mobile or tablet.

Notifications

Android N introduces new APIs to make notifications more interactive and highly visible. It has extended the existing notification API to support inline replies and bundle a similar notification into one notification.   Also, Android N adds new APIs that allow you to leverage system decorations in your app with customized notification views. The new notifications API has the following features:

• Direct Reply — With the Direct Reply feature in Android N, users can quickly respond to text messages or update task lists directly within the notification interface.

• Bundled Notifications — Android N provides developers with a new way to represent a queue of notifications: bundled notifications. This is similar to the Notification Stacks feature in Android Wear.

When to use Bundled Notifications?

You should use notification groups only if all of the following conditions are true for your use case:

• The child notifications are complete notifications and can be displayed individually without the need for a group summary.

• There is a benefit to surfacing the child notifications individually. For example:
  • They are actionable, with actions specific to each child.
  • There is more information to the child that the user wants to read.

What’s the impact on existing apps with Notifications?

Notification groups and remote input have been a part of the Notification API since Android 5.0 (API level 21) to support Android Wear devices. If you’ve already built notifications with these APIs, the only action you must take is to verify that the app behavior corresponds to the guidelines, and to consider implementing setRemoteInputHistory ().

In order to support backward compatibility, the same APIs are available with the support library’s NotificationCompat class, allowing you to build notifications that work on earlier Android versions.

ICU4J Framework API

This is an open-source set of java libraries that provide Unicode and globalization support for software applications. Android N exposes a subset of the ICU4J APIs in the Android framework for developers to use under the android.icu package. It uses localization data present on the device and that reduces APK footprint by not compiling the libraries in APK

Migrating from com.ibm.icu to android.icu package?

If you are already using the ICU4J APIs in your app, and the android.icu APIs meet your requirements, then migrating to the framework APIs requires you to change your Java imports from com.ibm.icu to android.icu.

Migrating from other Android APIs to android.icu package?

Some classes in java and Android packages have equivalents to those found in ICU4J. However, ICU4J often provides broader support for standards and languages. Example are:

1. i) util.Calendar to android.icu.util.Calendar
2. ii) text.format.Dateformat to android.icu.text.DateFormat

Java 8 Support

Android N introduces support for Java 8 language features that you can use when developing apps that target Android N.

Are all features from Java 8 now supported in Android N?

Android does not currently support all Java 8 language features. However, the following features are now available when developing apps targeting the Android N Preview:

• Default and static interface methods
• Lambda expressions
• Repeatable annotations
• Reflection and language-related APIs:
  • lang.FunctionalInterface
  • lang.annotation.Repeatable
  • lang.reflect.Method.isDefault()
  • and Reflection APIs associated with repeatable annotations, such as getAnnotationsByType(Class)
• Utility APIs:
  • util.function

Are these Java 8 features ready to use in Android Studio?

To start using these features, you need to download and set up Android Studio 2.1 (preview) and the Android N Preview SDK, which includes the required Jack toolchain and updated Android Plugin for Gradle.

Android N Platform doesn’t mandate using Java 8 features but you need to compile the application’s source code with JDK 8 if you want to use it in Android N.

You need to also use the new Jack toolchain. This new Android toolchain compiles Java language source into Android-readable dex bytecode, has its own .jacklibrary format, and provides most toolchain features as part of a single tool: repackaging, shrinking, obfuscation and multidex.

Here is a comparison the two toolchains used to build Android DEX files:

• Legacy javac toolchain: javac (.java –> .class) –> dx (.class –> .dex)
• New Jack toolchain: Jack (.java –> .jack –> .dex)

Tips When Working with Android N Developer Preview Multi Window Mode

• Use Context wisely. Do not inter change app context and activity context.
• Use Activity context to inflate the activity specific views and other resources.
• Do not use Application Context as it will be not aware of Activity specific theme or other resources.
• If you have added android:configChanges attribute in activity element in manifest, then do handle all the configuration changes as appropriately. Like loading dimension, layouts and other resources.
• Do not do too much in onCreate() or onResume() to make application resizing smooth, because whenever the user resizes the app, if you have not added android:configChanges attribute in activity element in manifest, then the OS will re-create your activity on each resize.
• Manage Landscape, portrait and window mode in configuration changes with proper layout rendering.
• Create your application UI as responsive as possible to make application resizing smother in the Multi Window mode.
• Apps with completely different layouts for mobile and tablet should avoid using the mobile UI on tablet in split-screen mode. Instead, the existing tablet UI should be adapted to fit the smaller size to ensure that users have a consistent experience on both devices.
• Use the proper aspect ratio for the screen sizes which your app is going to support.
• Be aware of inheriting properties
• If you launch an activity within a task stack, the activity replaces the activity on the screen, inheriting all of its Multi Window properties
• So, if in your app there are activities which can be started by the other applications then such activities must always need to support Multi Window.

How to test your application for Android N Developer Preview features?

If you directly install an application on Android N then there is a good chance that application will behave differently or it will not work at all. Hence it’s not a good decision to test the application directly on the new update. The development team needs to make the application compatible with the Android N developer preview first. After this, you can test a couple of features.

How to test for Doze mode

Configure a hardware device or virtual device with an Android 6.0 (API level 23) or higher system image.

• Connect the device to your development machine and install your app.
• Run your app and leave it active.
• Shut off the device screen. (The app remains active.)
• Force the system to cycle through Doze modes by running the following commands:

$ adb shell dumpsys battery unplug

$ adb shell dumpsys deviceidle step

You may need to run the second command more than once. Repeat it until the device state changes to idle.

• Observe the behavior of your app after you reactivate the device. Make sure the app recovers gracefully when the device exits Doze.

How to test App Stand By mode

1. Configure a hardware device or virtual device with an Android 6.0 (API level 23) or higher system image.
2. Connect the device to your development machine and install your app.
3. Run your app and leave it active.
4. Force the app into App Standby mode by running the following commands:

$ adb shell dumpsys battery unplug

$ adb shell am set-inactive <packageName> true

5. Simulate waking your app using the following commands:

$ adb shell am set-inactive <packageName> false

$ adb shell am get-inactive <packageName>

6. Observe the behavior of your app after waking it. Make sure the app recovers gracefully from standby mode. In particular, you should check if your app’s Notifications and background jobs continue to function as expected.

References

https://developer.android.com/preview/behavior-changes.html#ndk

https://discuss.zetetic.net/t/using-sqlcipher-on-android-n-preview-leads-to-segfault/1223

http://developer.android.com/preview/features/multi-window.html

https://medium.com/google-developers/5-tips-for-preparing-for-multi-window-in-android-n-7bed803dda64#.fqidic194

https://material.io/design/#split-screen-behavior

http://developer.android.com/preview/index.html