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

Anonymous (not verified) -
15 MIN READ

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 1st and 3rd 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.

Note that the value tier product line (e.g. TC2x) only supports a subset of MX and at the time of writing that subset does not include battery optimization, for more information see the TC2x feature matrix.

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

Enterprise Browser running on a newly reset Nougat device.  Note how the Chrome version in the user agent matches that reported by Chrome (58) Enterprise Browser running after updating the Chrome application on the device, the version still matches that reported by Chrome (60 at the time of writing)

 

There are some new Nougat features under ‘Developer options’ that you might find useful:

 

On GMS devices, you can choose the WebView implementation.  If you have Chrome Beta or Chrome Canary installed on your device, you can effectively test your WebView based application (e.g. Enterprise Browser) with an upcoming version of the rendering engine, avoiding unexpected rendering issues as you update your production devices with Chrome stable.

The Multiprocess WebView option also is available. This is something Google might enable in the future, but right now the company is just looking for community feedback.

The Android 7.0 change documentation states “Javascript run before page load: Starting with apps targeting Android 7.0, the Javascript context will be reset when a new page is loaded…”  Whilst it sounds as though this could have potential effects on Enterprise Browser’s DOM injection feature, it does not and the feature continues to behave as expected.

 

Android Enterprise – Device Owner

The official Google documentation for Nougat will refer to Android Enterprise features as ‘Android for Work’ (AFW).  The term AFW is no longer actively used by Google, so you will not see it used in Zebra documentation either. But the functionality being described remains the same; it is those features of Android that exist to satisfy enterprise use-cases.

 

The Android enterprise features changed for Nougat represent an incremental improvement over what was available in Marshmallow.  The documented updates to the DevicePolicyManager API are only a small part of the overall Android Enterprise story however: the entire solution depends on EMM compatibility, support for Zebra value adds and an upgrade path for existing customers from a Device Administrator to Device Owner mode.  It is outside the scope of this document to describe exactly which changes Zebra is making in Nougat to support an Android enterprise solution. I recommend you check other available Zebra documentation on this topic when available.

 

As a developer, the likelihood is you are not developing a Device Policy Controller application, so will not be interested in updates to the DevicePolicyManager APIs (such developers will typically be working very closely with Zebra to ensure maximum compatibility).  You are most likely to be affected by the move to Android Enterprise in other ways:

  • By using managed configurations to control your application’s configuration you can gain automatic benefits of server exposure via an EMM and the automatic configuration of those settings that goes along with that.  Existing techniques of configuring your app will still be possible e.g. via a file on the device but you will not have all the benefits of managed configurations.  For examples of managed configurations, I suggest you check out Google’s ‘Application Restrictions’ sample.  Application restrictions are the former name for managed configurations.
  • Managed android devices can be locked down through LockTask Mode.  Your application may find itself in an environment where only it is allowed to interact with the user, i.e. the user cannot escape from your app to configure some setting like disabling battery optimization.  If your application depends on another app somehow, e.g. by launching it through startActivity, then you will need to work with your device administrator to ensure both applications are whitelisted to run.
  • Interaction between your application and the Zebra device through EMDK will not change, the existing ProfileManager interface will remain in place and continue to function.

 

App Shortcuts

App shortcuts are a new feature added to Android Nougat that allow an application to expose common actions to the user that are accessed by long-pressing the icon on the launcher.

App shortcuts are supported by many Google apps available on GMS devices such as Gmail or Hangouts (see screenshot) as well as possibly being supported by a number of 3rd party apps.  If you are using these 1st or 3rd party apps, you might conceivably see a productivity gain as workers can now more quickly access frequent tasks.

 

No apps released by Zebra currently support app shortcuts.  Although supported by the default launcher on Zebra Nougat devices, app shortcuts are not supported by Enterprise Home Screen (EHS) so will not be available there even with apps that expose them in the default launcher.

The App shortcuts introduced in Nougat are a completely different concept to Enterprise Browser shortcuts, as explained at that product's techdocs page.

 

Image Keyboard Support & additional Emoji

Although Zebra devices support the new Image Keyboard support and additional Emoji added in Android Nougat, the recommendation for the best possible keyboard experience is to use Enterprise Keyboard (EKB).  EKB is a stand-alone product by Zebra that can be post-loaded onto the device. It features specific consideration for enterprise data entry such as remappable and custom keys and layouts, scanner integration and a colour scheme designed for easy viewing indoors and out.  EKB does support emojis, but priority is given to enterprise use-cases rather than ensuring complete compatibility with the latest Unicode emoji standards.

 

Versions

Android version 7.x sees Zebra devices starting to ship with MX version 7.0.

Some of the new features in MX 7.0+ are:

  • Battery optimization add and remove apps
  • BT silent pairing
  • Bug report Intent and Screenshot control
  • Wi-Fi 802.11ac and 802.11n configuration

For more information on MX 7.0+ please refer to the techdocs page.  More recently MX 7.1 has been made available which devices have already started to incorporate into their image.

 

Devices running Android Nougat also will start by shipping with DataWedge API 6.5 or 6.6, which provides a fully featured “zero code” capability for interacting with the device scanning hardware via intents.  For more information on the DataWedge API see the DW techdocs page, which also details how to determine your installed version

 

Bear in mind that both MX and DataWedge can only be updated through a full OS update.

profile

Anonymous (not verified)

Dfghjkjjn

Please register or login to post a reply

8 Replies

V Vedsatx Saddvv

Thanks John.&nbsp; I can't think of anything that has changed in N that should affect SOTI's ability to apply profiles and device encryption has been present since M so is not something recently changed.&nbsp; Our TC20 device running Nougat only supports a subset of profiles but the TC51/TC70x support remains unchanged.&nbsp; I saw a blog from SOTI that said they now support Device Owner mode on "Most Zebra devices" running N or higher but I haven't had any personal experience of it: <a href="http://www.soti.net/resources/blog/2017/soti-extends-android-enterprise…; , I would expect that Device Administrator mode would remain unchanged with their existing client.&nbsp; I suggest opening a support ticket for further investigation.

P Pietro Francesco Maggi

Hi John (or Matt?) :-)
File encryption changes usually applies only to devices that are released with Nougat at launch, not to devices that are updated to Nougat. So, the issue may lie somewhere else. Contacting Soti, as suggested by Darryn, looks like the best approach.

Keep in mind that Google started to limit the capability of applications with Device Admin permission in Nougat for security reasons:
<a href="https://developer.android.com/about/versions/nougat/android-7.0-changes… 7.0 Behavior Changes | Android Developers</a>
Device admins can no longer use <code>DevicePolicyManager.resetPassword()</code> to clear passwords or change ones that are already set. Device admins can still set a password, but only when the device has no password, PIN, or pattern.

The basic idea is that Google overcharged Device Admin with more and more functionalities over the years, but device admin was never intended to be used that way and it was starting to be a security liability.
Now, with Device Owner and Profile Owner available, Google is starting to limit Device Admin capabilities. This is why it's important to start new projects from day one with an MDM setup as Device Owner.

Last piece of the puzzle (till now).
Only one application can be setup as Device Owner, and this can be done when the device is clean (brand new or after a factory reset).
If you have devices managed with an MDM set as Device Admin, usually you need to factory reset them to install the MDM agent as Device Owner.
<a href="https://support.google.com/work/android/answer/6294687?hl=en">Assign a device owner to a managed Android device - Android enterprise Help</a>

Have a great Friday,
~Pietro

M Matt Dermody

Up until this point I have been leveraging Device Admin exclusively and only accidentally enrolled a VC80x into MobiControl in Device Owner mode and seemed a lot more limited in terms of what I was able to configure. If there can only be one Device Owner does that mean I can no longer use StageNow for staging along with SOTI for EMM?

Maybe you and/or Darryn could host a webinar covering the differences in management capabilities between Device Administrator and Device Owner.

D Darryn Campbell

A webinar on DO is probably a very good idea.

Anyway, StageNow is not running as a DO, so no problem on that side.
The idea for Nougat and newer devices is that you use StageNow to install the EMM agent of choice, set it up as the DO and enroll your device with the EMM.

~Pietro

M Michal Keracik

But ATM we have to skip (or go through)&nbsp; Google initial Wizard to get to StageNow, no?

V Vedsatx Saddvv

Hi Matt,

I have only personally heard about this from yourself...&nbsp; I believe you have raised this formally with Zebra as I have been cc'd on some emails - please reach out to me directly if you don't hear back on that.

Thanks,

M Matt Dermody

I've recently encountered some potential differences in how certificate access is handled in N. Previously, if an app was using an HTTPS/SSL connection with a self-signed Root CA issued server certificate the self-signed CA could be added to keystore on the device as a user cert via the Device Admin API through an EMM like SOTI. The app requiring the certificate for connectivity back to the host application server could leverage the user cert automatically with this process This worked for us on devices running Android L like the TC8000 and WT6000. Now with Android N, it would appear that Google has defaulted the behavior to either disallow access to user certs in the keystore or to not trust them automatically. A WT6000 on N in the exact same environment with the exact same configuration is unable to establish an SSL connection to a server while the L based WT6000s still can. I have found references the following reference which seems to indicate that the app needs to be recompiled with the custom request for access to the use the user certs in the keystore.

<a href="https://developer.android.com/training/articles/security-config">Network security configuration&nbsp; |&nbsp; Android Developers</a>
<a href="https://android-developers.googleblog.com/2016/07/changes-to-trusted-ce… Developers Blog: Changes to Trusted Certificate Authorities in Android Nougat</a>

Have you encountered this?

M Matt Dermody

Fantastic, as always! Thanks for the thorough breakdown Darryn! Is there anything in N that would affect the manageability of the device in a COSU Device Administrator management use case? I've recently update a few sample TC51s and TC70x's from M to N and now Soti MobiControl is no longer applying Profiles to the devices despite doing so with M. Is full disk encryption interfering? Could it be something else?