Hello Developers! Spring is here and so is the good news: Android™ 13 is available for Zebra devices!

Can’t wait any longer to explore its compelling new features? Follow me (and the official documentation) for a guided tour through its many advantages and learn how to deal with the changes this Android version is bringing to coders.

Android 13 has been publicly available since August 2022; you can read the official release notes here. You can appreciate this latest version has been designed with user privacy in mind and aims at improving productivity. It also promises to better render on large screens. As many developers are moving from Android 11 to Android 13, you might also want to learn the main changes affecting Android 12.

For a quick understanding of the changes from a developer’s perspective, it’s also advisable to review the list of behavioral changes affecting all apps running on Android 13 regardless of the target API level and the behavioral changes affecting apps targeting API33 and targeting API31-32. These are all good places to start looking for possible issues when upgrading or running your existing code in the latest version. I’m mentioning API levels 31-32 too because at Zebra we decided to skip Android 12. That happened for several reasons, such as: avoiding overwhelming our customers with a rapid succession of​ multiple OS releases, accelerating customers' access to new technologies like 5G, WiFi6, AI/ML, and the lack of relevant changes in Android 12 for the enterprise.

For the rest of this blog post, I’m going to focus on the most relevant challenges that you as an Enterprise developer could face when migrating your apps to Android 13 or just writing a new one from scratch, and I’ll guide you to avoid the most common pitfalls with the tools and features specifically designed by Zebra to make life easier for enterprise developers.

To nimbly move across the blog’s categories, here is a comprehensive table of content:

In a separate blog, I’m also covering the Direct Boot mode. It’s a niche topic, already introduced by Zebra in Android 11 for devices based on Qualcomm 6490 and 6375 chipsets. Android 13 however makes its adoption mandatory for all platforms from now on.  Readers who are keen to know more about direct boot can visit this page.

Foreground Services and Alarm Limitations

HEADS-UP!

As part of the new features from Android 13 that apply to all apps, the Foreground Service (FGS) limitations might impact enterprise apps.

Revisiting what happened over the years, Google has seen a growing misuse of background services, leading to faster battery draining and the denial of basic phone service because of that. So, restrictions on background services were introduced, leading to foreground services. The advantage of an FGS is its visibility to the end user, who is notified by each activity running behind the scenes. It has been a significant step forward, but many developers focused on FGS, with the overall effect of filling the notifications bar with icons.

With Android 13, new permission (POST_NOTIFICATIONS) is needed to add notifications to the panel. It’s dangerous permission, so it must be granted by the user. The only way to access and manage all the FGS is now the Task Manager, accessible from the notification drawer. Thanks to the Task Manager, users can stop a FGS. When the Stop action is triggered, the entire app is removed from memory, not just the FGS; the scheduled jobs instead execute at their scheduled time. It’s interesting to recall when apps are exempt from appearing in the task manager, so not being stoppable by the user, see here.

To mitigate the unplanned effect of this new feature from Google, you can leverage the Zebra MX API “UI Manager / Status Bar Disable” (accessible via Stagenow or EMDK) which has the effect to prevent users to pull down the status bar and gain access to the details of the notification and the newly added Task Manager. Alternatively, an EMM locked-down launcher may result in a similar effect.

It’s not the only change occurring: from API 31, a FGS cannot be started from the background. In other words, a FGS can only be started from a foreground activity. Since activities can be invisible, they can be a good alternative to this restriction: once the FGS is started, the activity can go away.

Google however provides developers with an exemption list with regards to the FGS startup – among the many, this one is likely to be relevant in enterprise space: “After the device reboots and receives the ACTION_BOOT_COMPLETED, ACTION_LOCKED_BOOT_COMPLETED, or ACTION_MY_PACKAGE_REPLACED intent action in a broadcast receiver.” When using this technique, be mindful to also mark your FGS as android:directBootAware="true". Don’t wait too long to call the FGS after receiving the actions above, as you risk getting a ForegroundServiceStartNotAllowedException! The “Status Bar Disable” introduced above also works well in direct boot mode.

DataWedge is also affected by the limitations of FGS started from the background, specifically the “Send via startService” and “Send via startForegroundService” in the Intent Output delivery mechanism don’t work anymore. As such, developers are advised to either switch to broadcast intents for data delivery or to startActivity as mentioned above.

Finally, a note on Alarms, which are no longer managed by the AlarmService class in the form of exact alarms. You need to obtain specific permission from the user (SCHEDULE_EXACT_ALARM) to be able to set and schedule an exact alarm. In Android 13 it won’t be granted automatically as happened in Android 12 - it requires user confirmation. Some more best practices on this theme are found here.

A new File browser app

GOOD TO KNOW

Though enterprise users don’t usually manage files via the File browser app, there are a few cases where users access the filesystem, not to mention developers that use it for setting up apps environment.

Up to Android 11, Zebra was able to leverage the AOSP version of the “Files” app and the DocumentsUI.

Starting Android 12, Google disabled file browsing through DocumentsUI; it can only be invoked from inside an app as a file picker.

In order not to break the user experience about file browsing, Zebra will be integrating into their Android 13 BSPs the “Files by Google” browser app during the first Android 13 release wave. This app is closed source, so no Zebra folders are accessible from there. Zebra plans to increase the functionality with the second release wave, expected by the end of May 2023, which will have equivalent functionality to prior Zebra Files Browsers.

Meanwhile, to access the Zebra folders from the launcher you have the following option:

Navigate to Settings / Storage, then tap Documents & other, and choose “Open with Files”: the Zebra folders icon is found on the bottom-left side of the screen and gives access to /data/tmp/public and /enterprise/usr.

Staging for Developers

Every Developer is a part-time Administrator!

BEGINNERS

We all have pondered about it, the Software Development Lifecycle – for many of us is the big framework where our job falls in. It can be split roughly into the initial stages of Planning and Designing, then moving into Development and Testing, and finally closing with the Deployment and Maintenance stages.

These few lines are all about the relationship between Developers and Administrators who own the Deployment stage and about the benefit to software quality when Administrators and Developers share their plans.

Zebra has a long history of supporting tools for the enterprise, all aiming at boosting productivity and shortening the release time. Some like Stagenow are specifically for administrators, others are solutions ready to be configured and deployed. In both cases, developers need to be fully aware of these tools and be able to manage them in the context of their software development.

There are at least three moments when developers and administrators cross paths:

1. To work within the right scope, developers must be able to reproduce a production environment on a local scale. With regards to mobile development, this is the moment when a developer is setting up a device with pre-defined profiles (e.g. a Datawedge profile, wifi), installing supporting tools (e.g. enterprise home screen), and updating its firmware and licensing software.
2. They must be aware of how administrators are going to deploy apps in production. What tools are administrators going to use? There are many options: EMMs (3^rd party software), zDNA Cloud, Stagenow (Zebra tools), manually. Will apps be configured through files or managed configurations?
3. Troubleshooting actions. When bugs occur, usually logs need to be collected and for high-severity cases, the whole device must be returned to the developer for analysis. Then a fix is released to an administrator and the loop closes.

For each of these phases, Zebra Stagenow is instrumental to operations success. Administrators can use Stagenow to initiate and complete the actions described above. Developers however can benefit from it too:

• Using Stagenow to set up the device where apps are developed and debugged is essential to creating a standard environment that can easily be reset when needed and shared with administrators once the app is ready.
• Most of the pre-configurations needed to set up a device are attained with Stagenow, reducing if not zeroing any runtime configurations.
• In several cases, Stagenow is entitled to perform privileged actions otherwise not attainable programmatically.
• If the device is centrally managed by an EMM, Stagenow is capable of staging its agent and kickstarting the work profile creation. This is a must for developers who need to develop with Android Enterprise in mind.
• When troubleshooting, Stagenow, if left accessible, can unlock a device and let developers pull logs and any other useful information about their app when it was used by operators. To safely allow this action, Stagenow offers the Trusted Staging feature which can protect devices with MX 9.2 and later from unauthorized staging. Trusted devices are created from a security certificate. Once a certificate is used to create a trusted device, the device can be staged only from barcodes created using the same security certificate.

A closing note on Stagenow is about the new OS internal architecture, called Skinnycat, designed to free up resources for improving the device's performance. Such re-engineering occurred starting with the release of Android 11 BSPs. One of the most relevant changes is the phasing out of XML as the language for profile definitions. Zebra has selected Android 11 as the "transitional" OS version. Zebra devices running Android 11 will accept both the old and the new configuration definitions. This is intended to allow organizations to continue using current methods for staging, persistence, and data and file sharing while gradually converting to the new methods being introduced.

Zebra devices running Android 13 (and later) will not accept scans of XML-based barcodes for device configuration. A solution to be included with Zebra devices running Android 13 allows XML to be pushed to devices by an EMM system or implemented from within an EMDK app to function without modification.

As an example, in the picture above, “PDF417” barcodes are XML-based barcodes and suitable for devices running Android up to version 11 included.

“JS PDF417” barcode must be selected and scanned on devices running Android 13 and optionally on those running Android 11.

When operating a mixed population of devices, spanning say from Android 8 to 13, you need to keep both copies of the configuration barcodes, scanning the old and the new versions according to what was stated above.

SSM – The Secure Storage Manager

ADVANCED---

Your companion tool for all storage needs.

And now I’d like to draw your attention to a tool that we at Zebra have specifically designed for developers. In just three letters it brings powerful features to coders, saving much work on your side!

 So, SSM means:

• SECURE – it enables a secure channel for transmitting data from one application (“originating app”) to another one (“target app”)

• STORAGE – In some cases, the target app isn't there yet, or not yet ready to receive that specific piece of data – so, here another SSM's feature comes in, the store-and-forward, which can be seen as a deferred-delivery mechanism. Since information storage is involved, it is secured as well.

• MANAGER - A managing part is in place because SSM is a singleton in the OS, it manages and keeps track of multiple connections and pieces of data, each from an originating app targeting one or more other ones. In other words, SSM is a shared resource that serves any 3^rd party or system app(s).

It’s not the first time apps need to securely hold and transmit data, so why so much noise about SSM? Why did Zebra create it?

The reason lies in the security tightening Google wanted to apply to data sharing use-cases. It all started with Android 10 and the introduction of scoped storage (though at the time it could be opted out). It was paving the way for an OS feature that would deeply impact applications since each app is entitled to only work within its scoped storage.

It's not however the only reason that caused some headaches for developers. Another mandate from Google is to phase out folders like /enterprise/usr and /data/tmp/public, which have historically been the place for loading apps’ configuration files. Such folders can introduce security weaknesses (trusted file renaming, file substituting, improper app clean-up on uninstalling). To allow developers enough time to review their app strategy on this point, we will keep them in place for the last time in Android 13 as they used to be. In the next major OS release version 14, the current plan is that users who need to access them will need to enable them and in Android 15, the current plan is that these folders will go away.

Having set a clear roadmap for public folders, developers want to leave them behind as soon as they can.

With your mindset finally aligned with the new Google standards concerning data sharing, it’s now time to see how to cope with the scoped storage limitations.

Scoped Storage

An application is only allowed to access content that is in its scope. In other words, it's an Android mechanism to limit the scope of storage that each app can access. It's the logical end point of a progressive restriction to the broader file system access that apps had in the past. Aside from those things that are in your scope, your app can't access anything that isn't expressively shared with it via a File or a Content provider.

An app scope consists of these parts:

1. The app's sandbox.
2. Shared media file folders utilizing SAF (storage access framework), which is a general-purpose way of including access to very controlled sets of shared media, including those media into the scope of an app - a sort of adopted scope.
3. Anything else shared to the app via File or Content provider.

Sharing across the border requires adopting secure tools made available by Android itself. It’s because of this big shift that designers and developers are given a reasonable amount of time to make their apps compliant.

Here comes the fun, why waste time reinventing the wheel, and implementing your providers? Simply pick the low-hanging fruits from SSM and focus on your business logic! That’s the real bonus from Zebra. Let’s see the advantage of using SSM in a simple use case.

Example: sharing a picture between two apps

Say you want to share a picture from app A to app B. Let’s compare two ways of doing that
 

As you can see, with SSM you have far fewer steps to care of and you get encryption as a bonus. And if the originating app requires a bit more work to access SSM, on the target app side the job is really at a bare minimum.

You could even reduce the steps above avoiding a file on the device at all. SSM can address source files as URI, so already available in a secured file server, and download them via https protocol. It’s the best choice since data is secured end-to-end.

Refer to https://techdocs.zebra.com/ssm/1-1/guide/share-files/ for a thorough coverage of the use cases. SSM is pre-built into Zebra OS images and is available for Android 11 (starting from BSP 11-23-13) and for Android 13.

Feeding files into SSM

Just a heads-up if you prefer dealing with the traditional filesystem when feeding files into SSM. Files to be shared via SSM must be placed in folders like /enterprise/usr and /data/tmp/public because SSM needs to access them freely. If files were put in the app sandbox, they wouldn’t be directly readable by SSM. Once a file has been fed into SSM, it can be removed from the filesystem, since SSM keeps a secured copy of it.

The perfect solution, if applicable to the case you are developing, is based on a File Provider. Here is a sketch of it and how it works.

The originating app creates a file in its sandbox, a location in the filesystem which is accessible to the app only. The internal cache is an example of it. This location is the basis for the App File Provider. Then the originating app calls grantUriPermission("com.zebra.securestoragemanager", …) to let SSM fetch the file once the file is inserted into SSM along with the target package name. These techniques are described on this page. This solution is secure-proofed since the app’s sandbox is inaccessible from outside the app, the file once in the local file provider can be accessed only by SSM. And once SSM gets it, the file is immediately stored elsewhere and encrypted. I’ve encoded these concepts in this Originating app and this Target app.

Notifying the Target app of a shared file

How does the target app know the URI that provides access to the shared file?

• The receiving app is notified when the file is available using a standard Android Intent
• The target app just needs to implement a broadcast receiver tuned on intent.getAction().equals("com.zebra.configFile.action.notify")
• Here is an example of setting up a receiver for SSM File sharing

Data Sharing and Notifications

SSM can also hold and share simple pieces of data:

• Suitable for loose data, not in form of files, and up to 10kB in size
• Implemented as key-value pairs with key uniqueness guaranteed.
• Works well in direct boot mode
• Target apps are notified by SSM of new data availability via standard Android ContentObserver onChange callback; Originating apps need to call getContentResolver().notifyChange to ensure the notification is triggered. Refer to this page for learning how to write an effective Content Observer and to this piece of code to see it in action.

Refer to https://techdocs.zebra.com/ssm/1-1/guide/share-data/

Looking in the mirror

A further use case enabled by SSM is about an app targeting itself when sharing data. A such case might be useful when:

1. The app received externally-encrypted data and needs to use that information in clear text- SSM can digest DET-encrypted data and return them in clear just to the specified app. Refer to https://techdocs.zebra.com/ssm/1-1/guide/share-data/#1preencryptdataoptional and DET doc.

This is a great feature for cases where an app’s owner needs to configure it with sensitive data and doesn’t want to share that sensitive information with an administrator. So, they have the option to pre-encrypt the data to be shared and send it encrypted to the administrator, who can deliver it to the app through several ways, like EMM Managed Configurations or via OEMConfig, without ever being aware of the actual configuration content.

2. The app needs to save some data for a future instance of itself - here is where persistence comes in since that information will survive an enterprise reset.

Refer to https://techdocs.zebra.com/ssm/1-1/guide/share-files/#applaunchedafterdeployment – use the parameter “secure_file_persist” or for Data sharing https://techdocs.zebra.com/ssm/1-1/guide/share-data/#4usecontentproviderapis – user parameter “data_persist_required”

3. Options (1) and (2) can even be combined to cover an additional interesting use case: securely saving sensitive data for future use. It’s like using SSM as a safe, where you can trustily store over time passwords, keys, and so on, that would otherwise require additional resources to be employed.

Secure Storage Manager in direct boot mode

Secure Storage Manager (SSM) Data Sharing works when the application is in direct boot mode. That’s a good piece of news, since - in terms of data security - more advanced use cases are enabled. Refer to this blog on Direct Boot for more information.

“SSM Data Sharing” stores and shares data with a high degree of security, since it optionally checks for the target app requesting data to match the app signature given when data were inserted. Additionally, for added data security, the originating app can optionally pre-encrypt data with Data Encryption Tool before storing data in SSM.  Such a higher security degree allows sensitive information to be accessed while both in Direct boot and normal mode, instead of just relying on the CES (Credential Encrypted Storage). With all the non-sensitive information stored in the DPS (Device Protected Storage), and the sensitive ones in SSM, the application functionalities are widened to the maximum degree.

Conclusions

• Secure Storage Manager was designed by Zebra to mitigate the scoped storage enforcement as mandated by Google and Zebra has introduced it well ahead of the current file-sharing practices being scrapped.
• It ended up not only being an effective point-to-point sharing tool, but it also brought end-to-end security plus persistence. The use cases that Developers can address with SSM are
  
  • App-to-app secure sharing
  • Secure Persistence, so App-to-itself
  • External DET-encrypted data to app
  • Securely storing data for future use (encryption+persistence)
• And on top of that, Zebra kept /enterprise/usr and /data/tmp/public folders available for at least one Android dessert yet, so developers have plenty of time to adapt their apps to the new standard.
• Zebra also designed OEMConfig to allow EMMs to deliver files and did the same file delivery easily via StageNow as well. So, if you as a developer prefer not to spend time tweaking the originating app to use SSM, you could even rely on external tools to deliver a file to a target app. And receiving files on the target side is straightforward. Visit this link.

Permissions

ROADMAP---

Don’t take that for granted!

Now, I’m sharing some thoughts about a feature introduced in Android 11 that might somewhat impact your applications. I’m referring to the Runtime Permissions Reset, which falls under a more comprehensive App Hibernation State. If your app targets Android 12 and above, and the user doesn't interact with your app for a few months, the system will:

• Reset the runtime permissions previously granted – as if the user pressed Deny when asked for that permission or as if the user went into App Info in Settings and Revoked that permission
• Not allow jobs and alarms in the background
• Not receiving push notifications
• Clear App’s cache

Permissions behavior, as set by Google, evolved significantly over time, requiring special attention by Zebra to offer enterprise customers a means to deal with them. The milestones have so far been:

• Up to Android 5.1, manifest-declared permissions – dangerous permissions are granted or denied at install time, and no special user interaction is required
• Starting Android 6 and up to Android 9, runtime permissions were introduced, to make users aware for just one time of what specific activities an app wanted to do
  
  • Users grant dangerous permissions to an app when the app is running
  • At this time Zebra introduced the silent app install feature for administrators who proactively preferred to make their choices around permissions granted on behalf of the end users. Stagenow offers administrators (and developers who are temporarily acting as administrators) a choice through Access Manager
• In Android 10 a new type of confirmation dialog is introduced: Users are prompted by the runtime permissions dialog to either always allow, allow while in use, or deny permissions
• But starting Android 11, permissions were set to expire and when it happens, permissions are taken away (reset), requiring them to be re-granted.
• Android 12+: Hibernation state including all the effects said above.
  
  • On this specific point, the permissions reset, Zebra is going to design a new mechanism to ensure permanent permissions pre-granting on a per-app basis as a new administrative feature. That will be part of future OS releases and proper communication will be done.
  • Chances are that the vast majority of our enterprise customers’ apps are Line-of-Business apps, so seldom left unused for months and at risk of incurring the permissions reset.
  • Until a facility to manage these situations won’t be in place, the recommendation for administrators is to re-grant permissions proactively as needed, more frequently than the non-use time should reset the timer.
  • Besides, always ensure that users don’t get access to OS Settings where they could manually revoke permissions. There are several lock-down options to prevent that.

Special runtime permissions

Since the introduction of the silent app install feature, however, Google wanted to provide users with more and more transparency over permissions granting and access to private data. That’s why Zebra preferred to limit the auto-granting mechanism, preventing a subset of dangerous permissions –selected appop and developer permissions – to be automatically granted. A few such permissions are manageable by Stagenow v5.8 (Dec.2022) and are listed in the picture below along with the three related actions of Allow, Deny, or return to Android default. The next Stagenow release will also add to the set new permissions from Android 13 plus more options to give administrators a fine-tuning knob for permissions settings. Zebra is so moving toward an explicit granting approach rather than automatic granting. For the permissions not listed below, users still must manually grant them.

Apps Auto-start

At Zebra we are also working on different fronts to make life easier for customers that need uninterrupted permissions and no business interruptions. Like permissions granting, app auto-start is another theme that customers asked us to focus on. There are common use cases around it:

• Set auto start-up for a newly installed app – without requiring the app to run
• Periodically run an app in the future – and ensure it didn’t lose permissions
• Re-start an app that was killed for any reasons
• Launch an app when a peripheral is connected

We are going to address these cases in our OS roadmap and once again the invite is to let us know what best suits your needs – as a pure developer or as a developer who is temporarily defining the administrative tasks around your app.

With these final thoughts, I’d like to thank you for staying on this page for so long, I hope you found it all useful, for your job and your overall knowledge of Zebra mobile computers.

Special thanks to my fellows Allan Herrod, Prashanth Kadur, Malvika Rajp, James Swinton-Bland

Android is a trademark of Google LLC.