What’s New for Android Pie and the Impact on Zebra developers

By Darryn Campbell

This document details the developer impact of moving to Zebra devices running Android 9.x Pie (API level 28), and is a follow-up to my previous posts about what’s new in Android Oreo, Nougat and Marshmallow. If you are moving from Nougat directly to Pie, I recommend you read the documents in sequence since all the information related to Oreo (e.g. background limitations or changes to the Google Play Store) is also pertinent to Pie.

Audience for This Document

Any developers targeting deployments featuring at least one Pie device or devices that will be updated to Pie should be aware of the changes detailed here.

Overview

As with each new version of Android, Pie introduces many new features, changes and enhancements that developers should be aware of before transitioning their applications to this new OS dessert. Google emphasises the artificial intelligence aspects of Android 9, and nowhere is that more evident than in the changes made to power management discussed in detail in this document. This release also continues the recent trend to add new features intended specifically for enterprise devices.

Google has published detailed overviews of the Pie changes on its developer portal. They’re broken down this way:

• Features and APIs
• Behavioural changes affecting all applications
• Behavioural changes only affecting applications targeting API level 28+

Google also has published detailed information around the changes to power management (including a table showing all power management restrictions) and an article that focuses on the specific changes made for enterprise devices & apps. There are many changes that affect all applications regardless of your target SDK, so even if you do not plan on making changes, it is strongly recommended by both Zebra and Google that you familiarize yourself with your application’s behavior on Pie and test it on the new OS.

This document does not replace recommendations from Google; it is designed to supplement those recommendations for enterprise use cases.

Power Management Changes

All versions of Android since Marshmallow have introduced some form of restriction on what applications can do in the background along with corresponding APIs and advice on how to develop an application to work with those restrictions in mind. All the changes—from Marshmallow’s Doze mode and Nougat’s enhanced Doze mode to Oreo’s background restrictions—have been cumulative, and the power-management changes in Pie are no exception. It is understandably quite daunting for any developer to try and fully understand everything that Android might do to stop their application running (and consuming battery) in the background and Google has addressed this with increasingly capable classes to defer your background work and schedule it to be done when some set of conditions are met (e.g. when the device is charging).

I have personally found that many of Zebra's enterprise customers want to understand the minutiae of device power management. This is understandable given the long lifecycles of enterprise applications combined with use cases that are quite different from consumer applications. However, an equal number of developers want something that "just works’ regardless of which device OS they are running on. I will try and cater to both groups by explaining the changes to power management in Pie before exploring the direction Google is moving in with the Work Manager class.

Standby Buckets & Adaptive Battery

Google first announced adaptive battery as part of its 2018 Pie preview whereby applications were categorized into “buckets.” Based on how frequently apps are used and which bucket they are in controls how much power that application is allowed to consume. The feature “App standby buckets” is an enhancement to the “App Standby" feature first introduced in Marshmallow. Where App Standby allows an app only to be either active or inactive, app standby buckets allow for far greater granularity.

As is detailed in the official documentation, the possible buckets into which an application can be placed and the effects of being in that bucket are explained briefly as follows:

Bucket	Description
Active	User is currently engaged with the application and Android considers it to be in the foreground Restrictions: none
Working set	Application is not currently active but runs often. Restrictions: Jobs and Alarms will be deferred. No restrictions on access to network or Firebase Cloud Messaging resources.
Frequent	Application is used regularly but not necessarily every day. Restrictions: Jobs and Alarms will be deferred for longer than applications in the working set. No restrictions on network access but Firebase Cloud Messaging is limited to 10 high-priority messages per day.
Rare	Application is not used often. Restrictions: Jobs and Alarms will be deferred for longer than applications in the frequent set. Network access is deferred and Firebase Cloud Messaging is limited to 5 high-priority messages per day.
Never	Application has been installed but never run. “The system imposes severe restrictions on these apps.”

Remember, these restrictions are in addition to other Android background restrictions. So for example, even if the application is in the working set, it’s also subject to Doze mode restrictions.

There is no API to request that an application be placed into a particular bucket, so a developer has little influence on where Android will put their app. However, the UsageStagsManager.getAppStandbyBucket() method is provided to determine which bucket an app is currently in. Application buckets are assigned and reassigned by Android as needed.

Applications on the Doze-mode whitelist are exempted from bucket-based restrictions. Through its MX Management Framework, Zebra exposes the capability during staging to either add an application to the whitelist or disable Doze mode entirely. Here’s how:

• To add an application to the Doze-mode whitelist, the App Manager’s “Battery Optimization Remove Apps” and “Battery Optimization Add Apps” actions can be used on devices with MX 7.0 or higher.
• To disable Doze mode entirely on your device then the Power Manager’s "DozeMode Enable / Disable" action can be used.

Note that “Remove Application for Battery Optimization” is analogous to adding the application to the whitelist.  For more information on “BatteryOptimization” please see the relevant section of the MX AppManager documentation.

Whitelisting your application or disabling Doze mode can increase the battery consumption of the device. For more information on whitelisting and background applications, please see the article on keeping your application running when the device wants to sleep.

For testing purposes, you can use adb to manually assign your app to an App Standby Bucket. To change an app’s bucket, use the following commands (as detailed in the Android docs):

$ adb shell am set-standby-bucket packagename active|working_set|frequent|rare 

You can also use that command to set multiple packages at once: 

$ adb shell am set-standby-bucket package1 bucket1 package2 bucket2... 

To determine which bucket an app is in, run:

$ adb shell am get-standby-bucket [packagename] 

If you don't pass a packagename parameter, the command lists the buckets for all apps.

Device developer options also allow you to see which bucket each application is in from Settings à System à Developer Options à Standby apps.

App Restrictions

The Application Restrictions feature is an evolution of Oreo’s background limits, but is more strict in Pie. An application in the background running on Oreo can receive Firebase Cloud Messages, but that same app—if restricted in P—will not receive any FCM messages regardless of their priority. Until it comes into the foreground, an application on Pie that is restricted will never have Jobs or Alarms fire, will have no access to the network or device location, and will not be able to receive Firebase Cloud Messages. App restrictions are designed as a way for the user to limit what an application can do in the background, so enterprises will typically want to prevent the user from configuring this.

Applications are restricted by the user either by:

• Restricting the app from the "Battery usage’ settings UI for that app (Settings à Apps & notifications à [Select App] à Advanced à Battery à Background restriction).

• Selecting to restrict the app from the list of misbehaving applications which Android automatically generates. This list can be seen on the battery settings screen (Settings à Battery) and will only allow users to restrict applications what have been deemed to be using excessive background battery. The criteria for an application appearing here is “excessive behaviour over certain thresholds,” such as excessive wakelocks. But those thresholds are not documented and OEMs can add custom criteria (Zebra has not made any changes in this area). An application being added to this list does not automatically restrict the app and manual intervention by the user is still required before any restriction is enforced.  

Android has detected a single application is using excessive battery in the background.

There is no way to remotely detect that a particular application has been restricted. Note that the terminology in the Device Policy Manager (EMM) documentation can be confusing since "Application Restrictions" is a completely separate feature. Android Vitals can report many of the same problems that lead to an application being considered to be using excessive background battery, e.g. excessive wake locks and administrators deploying their applications via the managed Play Store could consider using Android Vitals.

Author’s Comment: I tried to write an application that would misbehave and reproduce this warning to add colour to what "excessive behaviour" meant but was unable to do so despite multiple attempts with wake locks, alarms, background work and background services. I suspect that in most cases, other Android features that restrict background work may come into play before an application is deemed to have excessive use. The detection policy appears to be related to AnomalyDetectionPolicy.java which covers alarms, wake locks and Bluetooth scans. In the end I had to resort to using a 3^rd party application to generate the above screenshot.

You can view the restricted apps from the Adaptive Battery screen (Settings à Battery à Adaptive Battery à Restricted apps). Note that if you have not restricted any apps, then the “Restricted apps” option will not show on the Adaptive Battery screen.

Most enterprises will want their line of business applications never to be restricted. To achieve this, ensure the appropriate settings screens are not available to the end user. There are many ways to achieve this; a few are listed below.

• Zebra’s Enterprise Home Screen application can reduce the available settings to the user.
• Zebra’s MX Access Manager can restrict access to device settings during staging.
• Many EMM solutions offer the ability to lock down the device settings from the end user.
• Kiosk features of Android Enterprise can be used for task-specific devices.

For more information, please see Locking Down Your Device, an article on Zebra’s Developer Portal.

Battery Saver improvements

Battery Saver applies restrictions to all applications on the device. When turned on, Battery Saver takes steps to reduce battery consumption such as stopping all applications from performing background work and disallowing network access to any application not in the foreground. The best official documentation is on Google’s Battery Saver support page.

Battery Saver is not new to Pie, but it has been improved in a couple of ways worth highlighting here since I notice some external blogs conflate “Battery Saver” with the other App restrictions when discussing Pie.

Although disabled out of the box, Battery Saver can either be turned on manually by the user or be configured to turn on automatically at some specified battery percentage (15% by default).

The Settings à Battery à Battery Saver screen on Pie.

The table below compares the behaviour of Battery Saver on Oreo and Pie

Battery Saver	Oreo	Pie
Out-of-box state	Off; Battery Saver does not automatically enable	Off; Battery Saver does not automatically enable
How to manually enable	From the Battery Saver menu (Settings à Battery à Battery Saver) or Quick Settings icon	From the Battery Saver menu (Settings à Battery à Battery Saver) or Quick Settings icon
Supported "turn on automatically at X%" percentages	Supports only 10% or 18%	Configurable from 5% to 75%
How to turn off Battery Saver	Manually from Battery Saver menu / Quick Settings icon or by providing power to the device	Manually from the Battery Saver menu / Quick Settings icon. Providing power to the device only disables Battery Saver while power is applied

Most enterprises using Oreo and wishing to disable end-user access to the Battery Saver would have already locked down access to the device’s quick settings icons as well as the Battery settings screen. For more information on locking down your device, please refer to the earlier section on “App Restrictions."

You can use adb to manually control Battery Saver (as detailed in the Android docs):

To simulate the device being unplugged:

$ adb shell dumpsys battery unplug

To test how the device behaves under low power conditions:

$ adb shell settings put global low_power 1

Once you have finished your testing, you can undo your manual device settings:

$ adb shell dumpsys battery reset

Summary of Pie Power Management Changes

Google has given more user control over how applications use the battery. This includes allowing users to restrict individual applications and allowing the behaviour of the user to influence which app-standby bucket the application is placed in. In general, enterprises should limit what the user can do rather than give more control. But since most Zebra customers already use some form of lock-down over device settings, and Zebra offers full configurability over Doze mode, the actual implications of the new Background restrictions in Pie should be minimal for most Zebra customers. Bear in mind that power management changes will affect all applications on the device, not just those targeting API level 28+. So all developers should familiarize themselves with these changes.

To learn more about the details of the power management changes in Pie, I strongly recommend watching “Improving Battery Life with Restrictions,” a presentation from Google’s Android DevSummit in Nov., 2018. The presentation very clearly explains the specifics of how Alarms, Jobs and push messages behave with the different power restrictions.

 

Screenshots from “Improving Battery Life with Restrictions,” a presentation from Google’s Android DevSummit in Nov., 2018, which illustrate how the different power management restrictions affect different aspects of applications.

Work Manager

Scheduling background work on Android also has evolved. Google offers a guide to scheduling jobs which covers JobScheduler, AlarmManager, JobDispatcher and some other APIs, but the current advice is to start transitioning your background work to the new WorkManager class. WorkManager is designed to “replace” the previous APIs, although under the covers it is using the existing implementation. As a developer, you don’t have to worry about how the jobs are scheduled, you just care that they are.

I would recommend browsing the Google resources for WorkManager as well as a good article by the developer relations team on "modern background execution in Android." There are also a couple of good video resources: either the 6-minute introduction video or “Working with WorkManager,” a session from the Android Dev Summit in Nov., 2018.

From an enterprise point of view, the advice has always been to work with the changes Google is making to power management in Android wherever possible. WorkManager is an easy way to work with changes such as background restrictions and Doze mode without having to worry about the details. The trade-off is that background work might not occur at exactly the desired time, but the benefit is extended battery duration. I have personally used WorkManager in a few of my projects and have found it intuitive. However, if your use cases require applications to remain running continually in the background, WorkManager is not suitable for you, and you might be helped by the guidance I provided in “Keeping your Android application running when the device wants to sleep” on the Zebra developer portal.

Cleartext traffic disabled by default

Google have disabled insecure connections from applications targeting Android Pie or higher, this means that the isCleartextTrafficPermitted() method will return false by default.  If your app needs to enable cleartext for specific domains, you must explicitly set cleartextTrafficPermitted to true for those domains in your app's Network Security Configuration. 

We have seen this change affect some of our enterprise customers and this StackOverflow post gives a good summary of the developer options to deal with this.

Android Enterprise Behaviour Changes

Google has an entire page on its developer portal dedicated to the new features of Android Enterprise added in Android 9. Many of these features, such as the changes to the default launcher, switching apps across profiles and configuring the work profile lock screen challenge, are targeted at BYOD devices. Among the Android Enterprise additions, there also are some major developments targeted at task-specific devices (which is the category Zebra devices fall into), including enhancements to lock task mode and the introduction of ephemeral users, both of which are worth a much closer look.

Lock-Down Enhancements

In Oreo, it was necessary to specifically add lock-task mode support to an application either by calling startLockTask() or by specifying lockTaskMode in the application manifest. There are videos and descriptions of the behaviour of an application with these methods in the developer-portal post on locking down your device.

Under Pie, a Device Owner (DO) or Profile Owner (most typically an EMM is running in DO mode for our customer base) has the ability to put any whitelisted application into lock task mode using ActivityOptions.setLockTaskEnabled(boolean). Doing so enables any application to act in a "kiosk mode" environment without modification. For example, imagine my application wants the user to choose an image from the device gallery. As long as my application and the gallery application are whitelisted, my app can call startActivityForResult() and the user can pick the picture. At no point is the user given access to any button other than the back button (unless you use one of the new flags discussed in the next paragraph).

Lock task mode has been made far more configurable under Pie and is no longer restricted to displaying only the back button (as was the case under Oreo). Several new flags have been defined that a DO can pass to DevicePolicyManager.setLockTaskFeatures(flags). This is best illustrated with screenshots:

LOCK_TASK_FEATURE_NONE The default state, same as not applying kiosk mode	LOCK_TASK_FEATURE_SYSTEM_INFO Shows the time, Wi-Fi and battery icons, and the back button
LOCK_TASK_FEATURE_HOME Shows the home and back buttons (whitelist the launcher and set a default launcher for the home button work). Only whitelisted applications can be launched.	LOCK_TASK_FEATURE_NOTIFICATIONS Enables the notification shade to be pulled down. The application that created the notification need not be whitelisted for its notification to be displayed. The quick settings panel remains disabled.
LOCK_TASK_FEATURE_KEYGUARD Show the keyguard (password prompt when pressing power). This flag has effect only if keyguard is in place (e.g. you have set a PIN). If this flag is NOT set, the keyguard will NOT be shown even if there is a lock screen credential. This flag seems more applicable to public-facing kiosks than ruggedized enterprise devices.	LOCK_TASK_FEATURE_OVERVIEW This flag can be used only in combination with LOCK_TASK_FEATURE_HOME. When set, the overview (recent) button is displayed
LOCK_TASK_FEATURE_GLOBAL_ACTIONS The “global actions” menu is shown when the power key is held down. If set, this flag permits these power-key options to be shown.

There is significant overlap between the current capabilities of Zebra’s MX and the new Pie Lock Task mode flags. Customers with mixed deployments might wish to use MX until their device fleet has fully transitioned to Pie:

• The UI Manager’s Recent App Button Enable / Disable is analogous to the LOCK_TASK_FEATURE_OVERVIEW flag, though as previously mentioned, the latter flag requires that the home button also be shown.
• The UI Manager’s Home Key Enable / Disable is analogous to the LOCK_TASK_FEATURE_HOME flag.
• The UI Manager’s Notification Pulldown Enable / Disable feature has the same functionality as the LOCK_TASK_FEATURE_NOTIFICATIONS flag, though Zebra offers more granular configuration of the Quick Settings menu.
• The PowerKey Manager’s Touch Panel Show / Hide feature overlaps with the LOCK_TASK_FEATURE_GLOBAL_ACTIONS flag.
• The PowerKey Manager’s Automatic Screen Lock Enable Disable feature overlaps with the LOCK_TASK_FEATURE_KEYGUARD flag.
• The UI Manager’s Navigation Bar Enable / Disable can enable or disable the entire row of controls (back, home and recent). This has no corresponding flag as it also disables the back button but falls under the same category of features.

Ephemeral Users

Ephemeral users are an extension of Android’s multi-user capability and are implemented as secondary users deleted when the user logs out (stops) or switches away. Google’s developer documentation on multiple users goes into more detail but beyond the overview, it is aimed at EMM developers implementing multi-user capabilities in their EMM solutions.

Ephemeral users are designed to address the needs of enterprises such as:

• A public kiosk scenario
• Having a worker “log in” to a device for the duration of their shift and be able to “log out” at the end of their shift

In all cases, device state and any leftover app or user data are removed/reset automatically.

The EMM can control whether the user can log out manually with the setLogoutEnabled method or can trigger an automatic logout with the logoutUser API.

Ephemeral users require:

1. A device that supports multiple users and is running Android Pie or later
2. An EMM acting as a Device Owner and capable of creating secondary users
   
   1. The EMM will be acting as the Profile Owner for those secondary users
3. Since the EMM is managing both the Device and Profile, it can configure the profile (i.e. the ephemeral user) as required. This could conceivably include custom applications, settings or restrictions for that user based on who is logging in.
   
   1. A significant portion of the end-to-end solution for ephemeral users is dependant on your chosen EMM and how the solution exposes this capability. The exact capabilities might vary from one EMM to another.
   2. New user restrictions added in Android Pie include disallowing airplane mode. Such restrictions are placed on any created ephemeral (or secondary) user to control what that user can do.

In Oreo and earlier, the use cases for users logging into and out of devices for the clear majority of customers were handled entirely in software. Zebra devices started to support multiple Android users starting with Android Oreo, so there will undoubtedly be a period of transition if customers choose to move to the ephemeral user model at all. Returning a device return to a known state at the end of each shift and the security benefits of removing the user after use will no doubt be very appealing. Zebra devices running Pie support ephemeral users, and since this is a new feature, both Zebra and Google are keen to understand how well it meets our customer enterprise multi-user needs.

To better understand ephemeral users, I strongly recommend using Android’s Test DPC to enable the feature for yourself. I also put together a blog post on my personal website that includes videos of a device being configured with an ephemeral user and screenshots of the new user restrictions. Please bear in mind that content on my personal website is not endorsed by Zebra, but I felt it worth including here. Also, it was created in June 2018 using an emulator, so the visuals might look a little off.

Enhancement to DPM API

Many of the API enhancements listed in Google’s enterprise documentation for Android 9.0 relate to changes to the Device Policy Manager API. Those include Receive event notifications, Display event messages to users and Clear package data and remove accounts. Please bear in mind that only EMMs can take advantage of these APIs, and some are available only to EMMs working in Device Owner mode (sometimes called full device or dedicated device management). And although these features are available in Android and will work on Zebra devices, they still require your chosen EMM to expose them to you through their console.

Device Administrator: Migration and Deprecation

Migration of Device Policy Controllers (DPCs) is starting to get beyond the scope of this document but is worth mentioning here since Google includes it in the overview of enterprise features of Android 9:

• Device Administrator (DA) mode has been deprecated by Google as announced on its developer website. Starting in Android Q, the full functionality of DA mode will no longer be available.
• Where EMMs in the past used Device Administrator mode to manage devices, EMMs and customers are now transitioning to Device Owner mode (and Profile Owner mode, but that mode is used by far fewer Zebra customers).
• Changing from DA to DO mode (i.e. adding a Device Owner) requires a factory reset in standard Android.
  
  • A factory reset is unacceptable to most enterprise customers and Zebra has worked with Google to provide a way to migrate from DA to DO mode without requiring a factory reset. For more details see the DevTalk on EMM Overview (slides | YouTube)
  • For more information you can speak with your Zebra sales representative

• In Android Pie Enterprise features, Google refers to DPC migration in the context of DO-to-DO migrations only. This is an important distinction; with Android Pie, you can transfer from one DO to another DO for example if you want to switch EMMs or change your EMM agent without performing a factory reset. But this documented technique does not support DA mode.
  
  • Since DPC migration is a new feature in Pie, it is not possible to transfer from DO to DO with Oreo or Nougat using standard Android.
  • DPC migration would still require support by the EMMs you are transferring from and to.

Over-the-Air Updates

When reading Google documentation for postponing Over-the-air (OTA) updates, bear in mind that this is aimed at cellular carrier updates and the ability to postpone those carrier-delivered updates.

Zebra devices are updated through OS packages typically delivered by an EMM solution, although they also can be applied manually or through StageNow. This method allows administrators to push updates at a time convenient to the needs of their organization without relying on the Android update system.

Updates are available from the Zebra mobile computer support portal and are released frequently as part of Zebra’s Lifeguard program to ensure the latest security updates are always available. Lifeguard updates are released monthly for enterprise mobile computing devices and contain updates for Common Vulnerabilities and Exposures (CVEs) identified as part of the Android Security Bulletin for that month.

Other Features Worth Highlighting

While the advice Google gives generally applies equally to enterprise or consumer application development, the following sections are worth calling out to highlight the differences between the two user types.

Notification Enhancements

As with every previous Android version, Google has made several enhancements to the notification experience in Pie. Features such as conversation support and channel settings are enhancements of existing features, including Direct Reply introduced in Nougat and Notification Channels introduced in Oreo.

Notification Channels gave more control to end users over which notifications to allow or block. However, enterprise customers are likely to prefer to prevent the end user from blocking notifications. Some visual changes to the notification experience:

Notification	Oreo	Pie
Standard notification
Long press the notification	Clicking "MORE SETTINGS" takes the user to the application’s notification settings.	Clicking "Stop notifications" prevents the notification’s channel from being shown again. This can be reenabled from the application’s notification settings. Clicking the (i) symbol launches “App info” for the app.
After repeatedly dismissing the notification	No change in behaviour	User is given the option to stop showing notifications, disabling that notification’s channel.

A couple of observations:

• Long-pressing the notification behaves differently between Oreo and Pie. In Oreo, Zebra introduced a new MX feature designed to prevent the user from changing app notification settings through the "More Settings" option. This is the App Notification Control option in Settings Manager.
• Android Pie introduces a feature that asks the user whether to continue to show notifications after they’ve repeatedly dismissed them.

Recommendations under Android Pie for Enterprise apps:

• Continue to enable the Settings Manager’s App Notification Control option to prevent the user from accessing the application settings.
• Prevent the user from dismissing critical notifications by making them persistent and dismissing them from the application at the appropriate time.

Privacy

Android Pie introduces several changes related to user privacy. Those privacy changes affecting all apps are detailed in Google’s summary but there also are privacy changes that affect only applications targeting API level 28 or higher.

In summary:

• Applications are not able to use device sensors such as accelerometers, gyroscopes and the microphone when in the background. I have come across customers who use sensors to detect when the device is dropped or to initiate the scanner from the background. These use cases will be affected; Google’s recommended workaround is to use a foreground service.
• Some permissions involving access to phone numbers and call logs have changed, but the changes are likely to affect only a minority of enterprise apps. This would NOT affect proprietary communication mechanisms and applications such as Zebra Workforce Connect enterprise communication tool.
• Performing a Wi-Fi scan of nearby APs requires additional application permissions as detailed in Google’s documentation. The purpose is to limit an application’s ability to determine a user’s location without their knowledge and requires location to be enabled on the device to perform a Wi-Fi scan. The loophole being closed with these Pie changes is an application can no longer use the Maps Geolocation API to determine a user’s position without that user having location mode enabled on their device. This too is unlikely to affect enterprise applications.
• The Build.SERIAL number returns “UNKNOWN” and users are advised to use Build.getSerial(), which requires the READ_PHONE_STATE permission. This continuing trend further reduces the ability of an application to uniquely identify the device (the device MAC address was masked in previous releases). For now, Build.getSerial() will continue to work, but this is an area to monitor closely for applications that need to uniquely identify a device, which is commonly used in the enterprise for license management, for example.

Rotation

The changes to device rotation in Pie will affect only devices that lock their orientation. Devices configured to auto-rotate are unaffected.

The user is given control over which orientation to show an application when auto-rotate is turned off unless that application’s activity requests a specific orientation, such as by specifying screenOrientation as landscape in the Android Manifest or via setRequestedOrientation(). Where available, the user can control the orientation in Pie with a new rotate button shown in the navigation bar after the device is rotated.

Google provides detailed documentation describing the screen rotation changes, but in general I think most enterprise customers will be unaffected because:

• The user is typically denied access to Quick Settings or the Display Settings and could therefore not flip between auto-rotate and rotation lock (formally known as portrait mode)
• An enterprise user is typically switching between only a handful of applications that are likely locking the screen to a specific orientation, especially on devices with physical hardware scanners on the “top” of the device. This contrasts with consumer apps designed for devices that are frequently rotated and running alongside many other applications.

Restrictions on Use of Non-SDK Interfaces

Google has produced an entire documentation subpage describing the restrictions being imposed on applications calling non-SDK methods via reflection or JNI. Please consult that documentation for information on how to determine which APIs your application is using, details of the errors thrown and additional technical information about the different SDK lists.

In summary, interfaces are being categorized into several lists:

Whitelist Interface is part of the Android SDK No restrictions on use	Blacklist Interface can be called only by Platform apps Throws an error if otherwise invoked
Light Greylist No public alternative exists for API Warning generated if target SDK >= P API continues to function	Dark Greylist Warning generated if target SDK < P Throws an error if target SDK >= P

Although OEMs can add interfaces to these lists, Zebra has no current plans to do so.

Action for Enterprise developers targeting Pie devices:

1. Consult the Google documentation for "testing your app for non-SDK interfaces"
   
   1. Run your application on a Pie device or emulator (where possible) and observe any log messages or runtime errors because of blacklisted or dark greylisted applications.
   2. Run the veridex static analysis tool on your apk to detect calls to non-SDK methods via reflection.
2. Modify your application so it is not making calls to blacklisted or dark greylisted APIs.
3. Monitor use of APIs on the light greylist and transition when possible.

Indoor positioning with Wi-Fi RTT

Android 9 includes support for IEEE 802.11mc Wi-Fi, also known as Wi-Fi Round-Trip-Time (RTT), which lets you take advantage of indoor positioning in your applications.

Wi-Fi RTT requires:

• Wi-Fi APs that support 802.11mc
• Support in mobile device hardware (currently under development on Zebra devices)
• A server component and indoor maps to interpret the raw position data into a mappable location

Zebra has several indoor location solutions for multiple use cases and deployment sizes:

• Support for Visible Light Communication (VLC) in our latest mobile devices (press release)
• Dart UWB and WhereNet, both of which use dedicated hardware tags and sensors
• Smartlens for retail environments
• RFID with a range of available readers and accessories for Zebra mobile computers

Asset intelligence is fundamental to the solutions Zebra offers customers; there is no “one size fits all” technology for indoor locationing.

Neural Networks

Android Pie has updated the Neural Networks API to version 1.1. Note that this API is not yet supported on the SDM660 chipset; Qualcomm has instead opted to include its own SDK for the “Snapdragon Neural Processing Engine."

For more information about implementing machine learning on Zebra devices:

• 2018 machine learning webinar by Zebra engineer Rafal Firlejczyk
• Can a DSP Really Boost App Performance? by Zebra engineer Rafal Firlejczyk

Changes to the Google Play Store

In 2018, Google began requiring that applications posted to the Play Store target a recent Android API level. In 2019, the requirements as detailed in an Android blog post mandate the following timeline:

• Aug. 2019: New applications added to the Play Store must target API level 28 or higher.
• Nov. 2019: Updates to existing applications must target API level 28 or higher.

The new restriction affects only the target SDK; you can still assign any minimum SDK level. Google provides additional documentation for developers whose applications will run on devices with earlier versions of Android than that specified by the target SDK.

Though at the time of writing this restriction is not in place for applications solely delivered through the managed Play Store as private apps, there is no guarantee that this will continue to be the case in the future.