Why is Zebra changing its platform architecture?
A: Zebra is updating its architecture in reaction to requirements by Google to increase device security and data privacy, but also to modernize its platform and make it less proprietary. Zebra's "Mobility Extensions" (MX) framework was introduced in 2015, and has served reliably to control and configure Zebra's Android devices while helping Zebra customers and partners to avoid the complexities of platform signing. A proprietary system was required then because early versions of Android lacked the ability to interface with many Zebra-device features and peripherals, and very few centralized management systems existed to aid in device deployment across an enterprise.
Since 2015, Android has seen tremendous growth. Most of the interfaces Zebra first built are now part of the platform, accessible through public, non-proprietary methods such as Android Managed Configurations. This has allowed Zebra to shift its focus to platform innovation, value-added features and faster times to market. One such innovation was to decouple the application layer from the multiple proprietary underlying frameworks such as MX, allowing Zebra to develop its value-added solutions more reliably, in less time and with fewer dependencies.
What Are Delegation Scopes?
A: Delegation Scopes refers to a method by which the Android Device Policy Manager (DPM) APIs allow a device owner (DO) such as an EMM agent to enable other apps to use some DPM functions. Under Android 11 and later, an app can declare that access to its interfaces should be controlled, and that an administrator can be allowed to delegate access to other apps within a given scope. The Android DPM implementation of Delegation Scopes covers package and certificate management and a few other categories. Zebra has adopted and expanded Delegation Scopes to allow applications to control access to their interfaces by limiting their use to applications to which the administrator has granted a suitable Delegation Scope.
Developers that currently protect their app interfaces using MX/AccessMgr will need to change to protect their interfaces using Delegation Scopes and ZDM. Administrators that are accustomed to granting access to app interfaces using MX/AccessMgr will need to change to granting that access using Delegation Scopes and Zebra OEMConfig. NOTE: Apps that use protected services do NOT need to be modified for these changes. See the Delegation Scopes Usage Guide for more information.
Are Delegation Scopes and Zebra Device Manager related?
A: Yes, but the relationship is usually transparent to the developer. When an app attempts to use an interface that the implementing app has chosen to protect using a Delegation Scope, the implementing app queries ZDM to determine whether the calling app has been granted, by the administrator, the Delegation Scope that the implementing app has decided should grant access to that interface. Similar to using an "allowlist" or "whitelist" in MX/AccessMgr, the calling app would not really "know" that ZDM was involved, but should be designed to gracefully handle instances when the implementing app rejects the calling app's attempt to use a protected interface.
The exception is when the calling app accesses an interface indirectly, such as through an intent. As in the MX/AccessMgr model, the calling app must acquire a token, which in the new model comes from ZDM. The token is sent by the calling app via intent to the implementing app, which checks with ZDM to determine whether the token was issued to an app entitled to access the protected API. See the Delegation Scopes Usage Guide for more information.
Key Takeaways:
- Developers that currently protect their app interfaces using MX/AccessMgr must switch to using Delegation Scopes and ZDM.
- Administrators formerly granting access using MX/AccessMgr must switch to using Delegation Scopes and Zebra OEMConfig.
What is Scoped Storage?
A: Introduced with Android 10 (API level 29), scoped storage was originally intended to provide more user control over stored files and reduce the clutter that often occurs on external device storage over time. It limits apps targeting API 29 (and later) to an app-specific device folder and to media types it creates. In practical terms, scoped storage could limit or prevent an app from accessing device folders formerly available, including the /enterprise partition on Zebra devices. Enhancements delivered with Android 11 (API level 30) enforce greater protections on app and user data stored externally. Apps targeting Android 10 (API level 29) can opt out of restrictions imposed by Android 11 by setting a flag in the app's manifest. Apps that target Android 11 ignore this flag.
Upgrading to Android 11
An app installed on a device running Android 10 and specifying both the preserveLegacyExternalStorage and requestLegacyExternalStorage flags will not be subject to Scoped Storage if the device is upgraded to Android 11. But if the same app is uninstalled and then reinstalled after the upgrade to Android 11, or simply installed for the first time after the upgrade, the app will be subject to the Scoped Storage restrictions of Android 11.
Also see
Scoped Storage in Enterprise Apps | Info from Zebra engineering
Storage Changes in Android 11 | From the Android development community
What is the Android Content Provider model?
A: The Android Content Provider model is a set of publicly specified APIs through which apps can publish information about a given device for consumption by apps running on the device. The framework offers a unified and secure way of app data sharing.
What is Secure Storage Manager?
A: Secure Storage Manager (SSM) is an application built into Zebra devices running Android 11 (and later) that provides a mechanism for securely sharing data from an originating app to one or more specified target apps. The originating app can use SSM to share data with another app, or store data to be consumed by the originating app itself. SSM encrypts data while in storage and decrypts it upon delivery.
What is the Zebra Data Encryption Tool?
A: Data Encryption Tool(DET) is used to encrypt sensitive data shared among Zebra apps. It can be used alone or as an added security measure for SSM, which encrypts data only while in storage. When DET is used with SSM, data also is encrypted while in transit and upon delivery, leaving the responsibility of decryption to the receiving app.