What’s New for Android ‘N’ and the Impact on Zebra Developers

This blog details the developer impact of moving to Zebra devices running Android Nougat (API level 24 & 25). It is the follow-up to my previous blog about preparing for Android Marshmallow (API level 23).  If you are moving from Lollipop directly to Nougat, I recommend you read the blogs in sequence since all of the information related to Marshmallow (e.g. run-time permissions or doze mode) is also pertinent to Nougat.

 

Audience for this document

Zebra’s new TC20 and TC25 devices ship with Android Nougat installed.  Zebra's TC51, TC56, TC70x and TC75x can already be updated to Nougat and in due course, additional Zebra devices (both old and new) may receive the Nougat update.  Any developers targeting deployments featuring at least one Nougat device, or any devices that will be updated to Nougat should be aware of the changes detailed here.  Since Zebra devices are shipping with Android Nougat 7.1 (API 25) this document does not distinguish between 7.0 (API 24) and 7.1.

 

Overview

In contrast to some of the fundamental changes that took place in Marshmallow like dynamic run-time permissions, the changes introduced for Nougat should have less of an impact for Enterprise developers.  Google published an overview of the Nougat changes on its developer portal for 7.0 and 7.1 with more detail on Android 7.0 behavior changes also available.  This document does not replace recommendations from Google, but is designed to supplement those recommendations for enterprise use-cases.

 

Multi-window Support

Arguably the biggest change introduced in Nougat is support for multiple windows, displaying two applications to the user simultaneously, enabling them to multi-task.  Although Google will give use-cases such as watching a YouTube video whilst searching Google for recipes, it is not too difficult to conceive of enterprise use-cases, especially where a worker needs to quickly switch between two applications to perform their job.  Google has additional information on multi-window mode available on their developer portal.

 

Multi-window mode will work on Zebra devices, but if you are looking to support it with your application, it is worth bearing the following in mind:

• There is no way to provision the device to launch in multi-window mode, or to (easily) prevent the user from exiting the mode or preventing them sliding the divider to give one application more real estate than another.  Entry into multi-window mode is controlled entirely by the user, so you should not design your application to run exclusively in multi-window mode.
• The ergonomics of Zebra devices are designed around an application running full screen; elements such as the position of the hardware trigger will have been exhaustively user-tested for usability in the standard orientation.
• Although two applications are displayed, only a single application can be the “active” app. If you are expecting scanned barcode data to arrive in your application via DataWedge as keystrokes, these will be sent only to the active application.  Because the active application depends on which app was last touched by the user, this could lead to confusion and missed scans if the user inadvertently taps the other visible application.
• Multi-window mode will not work with Enterprise Home Screen (EHS), you cannot enter multi-window mode if EHS is your launcher application.

 

Your app can report support for multi-window by specifying android:resizeableActivity="true" in its manifest under either the <activity> or <application> element.  The following table shows whether an application supports multi-window:

Manifest / API level	Result
resizeableActivity not specified Target API level is 24+	resizeableActivity assumed to be ‘true’ Your application is assumed to support multi-window. No toast is shown when multi-window is started
resizeableActivity is ‘true’ Target API level is 24+	Your application is explicitly stating support for multi-window. No toast is shown when multi-window is started
resizeableActivity is ‘false’ Target API level is 24+	A toast is shown when multi-window is started: “App doesn’t support split screen”
resizeableActivity is not specified Target API level is 23 or below	A toast is shown when multi-window is started: “App may not work split screen”
(for completeness) resizeableActivity is ‘true’ or ‘false’ Target API level is 23 or below	Application will not build, no resource identifier found for resizeableActivity.

 

Not all out-of-the-box applications provided by Zebra will support multi-window mode. For example, the DataWedge Demo app by design does not support it so that it avoids the potential confusion described earlier about which application will receive scan data.

 

A developer or administrator looking to prevent the user from entering multi-window mode can do so by suppressing the ‘Recent’ key.  If supported on your device, this can be done via the MX UI Manager or  MX KeyMappingManager and remapping the key using the ‘Suppress key’ parameter.  Other options include using Enterprise Browser (<setRecentAppDisable value=”1”>) or initiating lockTaskMode if your Android device is managed.  Disabling the ‘recent’ key also will prevent the key being used to switch between applications, so this workaround may not work for everybody; it may be better to ensure that required applications work well with multi-window mode or report resizeableActivity as ‘false’.

 

MX8.1 introduced the "Split Screen Enable / Disable" parameter to the UI Manager, this can be used to control whether or not multi-window is available however this parameter is not available on Android Nougat or earlier.

 

Notification Enhancements

Messaging is a big use-case for many of our enterprise customers and in two ways these have received great improvements:

• Direct reply allows users to reply to messages without leaving their current application, i.e. they do not have to switch out to the messaging application in order to send a reply.
• Bundled notifications allow an application to choose how messages are grouped to a user. For example, email conversations can be bundled by subject to avoid clutter.

 

Other notification enhancements are detailed on Google’s developer page and can be easily integrated into your application.  Also consider if you are using managed Android devices and deploying applications through the managed Play Store you are likely already using popular 1^st and 3^rd party applications such as Gmail. If this is the case, you will likely get these kinds of new features for free without any additional development effort.

 

The notification UI has received an update:

 

Description	Screenshot
Sliding an application to the right will reveal a small cog icon
Pressing on the cog icon revealed in the previous step or long pressing on the notification will bring up a drop-down that allows the user to silence or block notifications.   From MX7.2+, it is possible to prevent the user from disabling notifications in this way, please see the Settings Manager's App Notification Control. Above: Out of the box behaviour. Above: Notification Control set to 'Disable'
If the users press on ‘MORE SETTINGS,’ they are taken to the Notifications settings for your application. This is the same screen as is shown if the user navigates to Settings --> Apps --> <App> --> Notifications; it also allows the user to block notifications associated with your application.   As with Android Marshmallow, the only way to reliably block access to the ‘Notifications’ settings screen is by using the Access Manager’s ‘system settings access’ parameter to limit access to all but a small subset of settings.

 

Additional notification control is available via the System UI tuner and branded ‘power notification controls.'  I cannot find any specific Google documentation on these, but searching for ‘android power notification controls’ reveals a number of blogs that go into detail.  To disable this feature, the easiest thing to do is to disable the System UI tuner entirely (as detailed in the “What’s new for Android ‘M’” document) or to disable user access to the device settings.

 

Doze Light / Doze on the Go

Android Nougat enhances the Doze mode introduced in Marshmallow by allowing a moving device to now be subject to Doze mode whereas previously only stationary devices were able to doze.  Google’s documentation on the subject is comprehensive. The delta between Marshmallow and Nougat doze, as explained by Google, is the same on both consumer and Zebra devices.

Figure 1: Doze mode as explained by Google's developer docs

 

All the advice given under “What’s New for Android ‘M’ and the impact on Zebra developers” still applies. Also be aware of a more thorough blog explaining how to keep devices awake and the interaction between doze mode, wake locks and wifi locks.

 

Zebra devices running Android Nougat are running MX 7.0, and therefore will support the newly introduced BatteryOptimization action added to the App Manager in that version.  “Battery Optimization Remove Apps” and “Battery Optimization Add Apps” are features of the App Manager that allow you to add or remove an application from the Doze whitelist respectively.  This enables you to whitelist an application so it is not subject to doze mode without requiring the user to perform any manual steps.

Figure 2: Whitelisting an application via EMDK (requires MX 7.0+)

 

Update (March 2018): From MX 7.2+ it is now possible to globally disable doze mode using the MX Power Manager.

Figure 3: Disabling doze mode globally on the device (requires MX 7.2+)

 

Background Optimizations

The background optimizations introduced in Android Nougat are detailed on Google’s Android developer portal.  There are probably no specific changes to be made to your application at this stage, but it is worth noting that these ‘N’ changes are laying the foundation for the upcoming background optimization features happening in ‘O,’ which have a greater potential effect on applications.  It is too early to offer recommendations on developing apps for Zebra devices running Oreo, but should you wish to update your app in line with the advice Google is giving for consumer apps, you can start doing that now. Changes such as making use of the JobScheduler or GCMnetworkManager APIs have been possible since Lollipop, but Nougat enhances the capability of JobScheduler and starts to introduce some restrictions on specific broadcast intents.

 

Data Saver

Android Nougat introduced a Data Saver feature that blocks background data usage and signals foreground apps to use less data where possible.  On Zebra devices, most use-cases revolve around wanting an app to have access to a data connection if required for business-critical actions. It is therefore unlikely the device administrator will want to enable “data saver” on Enterprise devices.

 

Remember, data saver only affects WAN devices, so if a device does not have a cellular connection (e.g. TC20 or TC51) the option will not be available.  No specific MX feature is available to enable or disable data saver, so it is recommended that you ensure device users do not have access to the settings app to avoid undesired throttling of the data connection.

 

Quick Settings Tile API

Android Nougat introduced a new API to allow applications to add icons to the quick settings tiles (i.e. those icons shown when you swipe down from the top of the screen), which are commonly used to quickly enable or disable system properties such as Wi-Fi, Bluetooth and Airplane mode.

 

You certainly could take advantage of this on Zebra devices; the screenshots below show a sample app I modified from another blog:

 

 

Quick Settings Tile API	Quick Settings Tile API
Test application that displays the Zebra logo as a quick setting tile	Clicking the quick setting tile invokes the owner app’s TileService.  In this case, I just launch the owner app. However, Android documentation specifically states you should not use quick setting tiles as application launchers(!)

 

 

Just because it can be done does not necessarily mean it is a good idea to do it on an enterprise device.  There is no way to automatically provision the quick setting tile. After app installation, the user (or administrator) is required to perform the following steps:

• Pull down notification shade
• Click “edit” (pen)
• Scroll down to the unused tiles and drag the required tile into the main tray
• Exit from the edit screen

 

It is far more likely that an administrator would want to prevent the user from accessing the notification shade as it is often undesirable to give the end user the ability to disable Wi-Fi or Bluetooth on the device since this could prevent them from doing their job.  There are currently no plans to provide granular control over the tile window to allow some tiles but disallow others. So for the vast majority of customers, the new Tile API is not a good fit for their enterprise use-cases.

There are many ways for an administrator to prevent the user from pulling down the notification shade: Enterprise Android devices can use lock task mode; Enterprise Browser supports the <SetStatusBarDisable> configuration setting, and MX exposes the capability through the UI manager.

 

Chrome update also updates the WebView

In previous versions of Android, applications making use of the WebView would receive updates to that WebView on GMS devices via the PlayStore with the ‘System WebView’ package. In Android Nougat, this has changed so applications using the WebView component have that component updated as the Chrome application is updated, and the ‘System WebView’ package is no longer applicable.

 

This affects Enterprise Browser (EB) on GMS devices, the rendering engine used by EB will update in line with any Chrome updates on the device.  Compare the following screenshots taken of both Chrome and EB as Chrome is updated:

 

 

Chrome running on a Nougat device out of the box.  The pre-installed version of Chrome is 58	Chrome running after receiving the latest available update from the Play Store