Before you Upgrade your TC70s to Kit Kat
This document is for administrators and anyone managing or deploying Zebra TC70 mobile computers.
The first release of the TC70 (referred to as the GA1 release) was Android Kit Kat 4.4.2.
The next release (referred to as GA2, or the Maintenance Release) is Android Kit Kat 4.4.3, and contains
some changes which may not be obvious but may have important effects on some of your applications.
Changes occurring in the GA2 build of TC70 Kit Kat
Changes that begin with the GA2 build are in three groups:
1) Enforcement of the “Kit Kat changes” in external storage permissions meaning that multiple
volumes are officially supported but file access (security) rules have changed;
2) changes in the configuration of external storage which implement a more “industry standard”
configuration;
3) changes in permissions on a couple of key directories, required to stay compatible with Android
in general; and
4) changes in the naming of packages built in to the TC70, brought about by the “rebranding” of
our devices now that we are part of Zebra Technologies.
Applying the GA2 build (aka the Maintenance Release) to already-deployed TC70s may cause some apps
to malfunction. This document will tell you what to look for in your applications that may indicate the
need for an updated, “truly Kit Kat compatible” version of an application.
Changes in the File System
Note that since the first build of the TC70 did not require complete compatibility with the new
permissions regime for External Storage volumes (or colloquially “sdcards”), some applications that
won’t run on a “full Kit Kat implementation” (like the GA2 release) may have been used successfully on
the earlier TC70 release.
Changes Related to Storage Organization and Permissions
In Android, "external" storage includes both actual, removable memory cards ("SD cards") and built-in
storage volumes that emulate or work like permanently installed memory cards. This can be confusing
because some external storage volumes are built into the device.
The TC70 supports a removable SDcard, as well as a permanently installed 1G built-in FAT partition that
is also configured as an external storage volume. In the GA1 release, the “Primary” external storage
volume is the removable sdcard, and the 1G built-in external storage volume is a “Secondary”. And
since in the GA1 release the Kit Kat rules for file access on external storage volumes are not enforced,
applications are able to write files in the root of either volume. With the new GA2 release this situation
reverses – the 1G built-in external storage volume will be the “Primary” and the removable sdcard will
be a “Secondary” – and the Kit Kat access rules will be enforced. This may cause files written by
applications to the removable sdcard to become inaccessible to their applications once the GA2 build
has been installed. In particular, applications will not be allowed to create or delete files in the root of
the removable storage card because it will be a Secondary external storage volume. Applications may
be allowed to read existing files there if they request and are granted the READ_EXTERNAL_STORAGE
permission.
Changes Related to Enterprise Persistence
In addition to changes in external storage, the GA2 Maintenance Release brings changes in “enterprise”
storage. The system uses the /enterprise partition to store critical information, and allows applications
to put folders and files under /enterprise/usr in order to persist them over an Enterprise Reset.
Use of /data/tmp Disallowed
The new GA2 release changes the permissions on the system folder "/data/tmp" folder. Prior to GA2,
applications could write files in /data/tmp. This was found to be inconsistent with our security direction
and is no longer allowed.
Effects on New and Already-Deployed Applications
If you intend to deploy new applications to your Kit Kat TC70s, then you will need to be sure those
applications make proper use of external storage and enterprise storage. Non-system applications (that
is, applications not delivered as part of the OS) will no longer be allowed to use /data/tmp for storage.
If your already-deployed TC70s have any applications installed which use external storage, enterprise
storage, or the /data/tmp folder, you should plan your upgrade to the GA2 release carefully, in order
to avoid “broken” applications or lost data.
Program Namespace Changes
As a result of Zebra Technologies purchase of Motorola Solutions’ Enterprise Business, we are legally
required to “rebrand” our devices. Some of the changes are cosmetic – you will see for example a Zebrabranded splash screen during startup – and these cosmetic changes have no effect on applications. But
some of the changes relate to the internal “namespace” used by Zebra functional additions to our
Android devices. Programs that take advantage of Zebra “value added” functionality such as scanning,
advanced networking capabilities, or enterprise-scale management features may need to be updated.
We have tried to minimize the impact of the namespace changes by providing as much backward
compatibility as possible, and many programs may work unchanged on the new Kit Kat release, but a
few programs may need to be rebuilt to use the new namespace. Backward compatibility around the
namespace issue is not guaranteed beyond Kit Kat.
How to Tell if your Applications May Need to be Upgraded
Applications may be affected by changes in file access (permissions)
Your applications will likely need upgrade if they use ANY of the following storage areas.
1) External storage volumes, including emulated or actual “SDcard” volumes.
2) Enterprise storage, meaning any folders under “/enterprise”.
3) The specific folder “/data/tmp”.
If any of your applications use any of these storage areas for files or folders, please see Appendix 1:
Changes in Storage Organization and Accessibility, for specific information on how applications may
need to change to function correctly in Kit Kat.
Applications may be affected by changes in internal package naming (to Symbol)
Applications may also need to be upgraded if they take advantage of Zebra’s “value added”
functionality. Application developers should review the information in Appendix 2: Effect of Internal
Namespace Changes.
Use of “Configuration APKs” Interim Configuration Method
A few customers may have deployed one more “configuration APKs” as an unsupported, interim
solution for device configuration. Specific application names this group are: AccessMgr.APK,
AppMgr.APK, CertMgr.APK, Clock.APK, PowerMgr.APK and WiFiConfig.APK. If you have deployed any
of these packages, you will need to take one of the following actions:
1) obtain updated versions of those (unsupported) APKs and deploy them just before upgrading to
the rebranded Kit Kat operating system or
2) Use a supported method to submit to the MX Management System the same the XML you are
now using with the APKs, MX Management System.
Note: the “configuration APKs” were an interim method only and are now deprecated. Customers using
the configuration APKs should plan on switching to a supported configuration method. Currently
supported configuration methods include only use of a Tier1 MDM (SOTI or AirWatch), use of Zebra’s
StageNow product, and development of custom applications using the Zebra EMDK.
Appendix 1: Changes in Storage Organization and Accessibility
System folder “/data/tmp”
The folder “/data/tmp” was world writeable in Jelly Bean. This was incompatible with standard Android
design and has been corrected in the GA2 Kit Kat release. Non-system applications that previously used
the folder “/data/tmp” for temporary storage should be changed to follow Android best practices for file
temporary file creation – see getCacheDir() and its use.
Enterprise Storage under “/enterprise/usr”
In the TC70, /enterprise is a partition that is used by the system to persist certain settings and
applications over an “Enterprise Reset. This is not a large partition but area but the folder
“/enterprise/usr” exists to allow non-system apps to persist critical files over an Enterprise Reset.
Permissions on files stored under /enterprise/user must be wide open (777) so that each application can
regain full access to its files after an Enterprise Reset, when its Linux userid (used to determine file
access rights) will have changed.
In previous builds, the system would automatically set all files and folders under /enterprise/user to
777. In the Maintenance Release, this will no longer happen – so each application must be sure that the
permissions on all files it creates are set to 777. Failure to do so will result in the application not being
able to access its files after an Enterprise Reset.
External Storage
In earlier versions of Android there were no APIs that recognized more than one external storage
volume, although it was common for manufacturers OEMs (like Zebra) to supply more than one. In
order to use these extra storage options, developers often hard-coded a path to external storage, and
often wrote their files and folders in the root of an external storage volume.
Kit Kat storage rules do not allow applications to write files to Secondary external storage except in their
“dedicated folder” (or “sandbox”), which is named for the application package and located on each
external storage volume under the Android/data folder on each external storage volume.
With Kit Kat, it has become more important to use the improved APIs to find or specify a path to a
usable folder in external storage. Application developers should familiarize themselves with the new
APIs for external storage and with Android’s new rules for file access. With the GA2 release, path
names on the TC70 will change. Applications that have hard-coded path names may not longer find their
files under those hard-coded pathnames, or may no longer able to access them.
The TC70 has a built-in, 1Gb external storage volume and a slot for insertion of a removable sdcard.
Since the GA2 Maintenance Release enforces the Kit Kat rules for program access to files on external
storage volumes. Since on the TC70 the built-in, 1Gb external storage volume is the Primary – which
means that if you are using a removable sdcard it will be a Secondary external storage volume and
applications will not be able to write files in the root of that drive.
Appendix 2: Effect of Internal Namespace Changes
A primary goal of the rebranding effort has been to minimize the impact to our customers and their business
operations. It is expected that most applications will have little or no impact due to the brand-related namespace
changes, but each application should be tested for Kit Kat compatibility. The most common reason why an
application might need to be changed is if it explicitly interacts with some aspect of the device using a name that
had to be rebranded. The areas that have changed and should be reviewed are identified below.
References to the Manufacturer Name
Applications that query the device Manufacturer will need to check for a return string of “Zebra Technologies”.
Rebranded Kit Kat devices will have the following System Property change:
Android.os.Build.MANUFACTURER = Zebra Technologies
Rho Mobile Suite
Formal support for rebranded Kit Kat devices will be available in RMS 5.2. As an application development
framework, to meet the security requirements of Kit Kat, and to take advantage of new features, customer
applications will need to be recompiled to operate on RMS 5.2.
Deprecation Highlights
While all efforts have been made to limit the impact of the rebranding on existing applications, applications
written for Motorola branded devices may require modifications to run on Zebra devices. The following are some
of the important points to consider while modifying your applications:
1.
Programmatically determining if a device is rebranded – In most cases, it is possible to write a common
application to run on both Zebra as well as Motorola branded devices. The following method can be used to
determine if a device is rebranded:
Zebra is using “symbol” as the new “internal brand” for our Android devices. If the system property
“ro.sys.brand” exists and returns “symbol”, then the device has been rebranded.
2.
Package names – All packages using the Motorola name (com.motorola..) have been rebranded. Applications
performing operations such as launching a package must be modified to use the rebranded (com.symbol..)
package name.
3.
API Intents – All intents previously using the com.motorola naming convention have been rebranded to use
the com.symbol naming convention. While not documented for new use, the older Motorola named intents
(com.motorola…) will still be supported for backward compatibility but they are being deprecated. Zebra will
remove support for Motorola intents in the near future. It is strongly recommended that applications are
modified to use the Zebra rebranded intents as soon as possible.
4.
EMDK APIs – The EMDK APIs do not require any code changes or recompilation.
5.
Legacy configuration mechanisms – though the interim “Provisioning APKs” are now deprecated, rebranded
copies are available for customers that have already employed them (no net-new deployments).
6.
Enterprise Utilities – The MultiUser Administrator, AppLock Administrator and the Secure Storage
Administrator make up the on-device Enterprise Utilities. Version 4.0 and later of these utilities will support
both rebranded and non-rebranded devices. Customers using these utilities will need to upgrade to Version
4.0 or later.
EMDK – device compatibility process does not change
Package Name
None of the EMDK components require any rebranding. The EMDK Package name remains the same:
Existing Package Name
Rebranded Package Name
com.symbol.emdk
com.symbol.emdk
APIs
There is no rebranding impact on the EMDK APIs. Applications developed using the existing EMDK can
be used on Zebra branded as well as legacy Motorola branded devices. There is no need for code
modification or recompilation.
DataWedge Name Change
Package Name
The DataWedge package has been rebranded as follows:
Existing Package Name
Rebranded Package Name
com.motorolasolutions.emdk.datawedge
com.symbol.datawedge
Profiles
The existing DataWedge profiles (stored in the datawedge.db file) are fully compatible with the
rebranded DataWedge. There is no need for any modifications.
API Intents
The existing DataWedge API intents are still supported for backward compatibility but they are being
deprecated. It is strongly recommended that applications are modified to use the rebranded intents as
soon as possible:
Existing Intent Name
Rebranded Intent Name
com.motorolasolutions.emdk.datawedge.api.
com.symbol.datawedge.api.
ACTION_SOFTSCANTRIGGER
ACTION_SWITCHTOPROFILE
ACTION_SOFTSCANTRIGGER
ACTION_SWITCHTOPROFILE
ACTION_SETDEFAULTPROFILE
ACTION_SETDEFAULTPROFILE
ACTION_RESETDEFAULTPROFILE
ACTION_RESETDEFAULTPROFILE
ACTION_SCANNERINPUTPLUGIN
ACTION_SCANNERINPUTPLUGIN
ACTION_ENUMERATESCANNERS
ACTION_ENUMERATESCANNERS
ACTION_ENUMERATEDSCANNERLIST
ACTION_ENUMERATEDSCANNERLIST
EHS Version 2.0 supports rebranded devices
Package Name
The EHS package has been rebranded as listed below:
Existing Package/Main Activity Name
Rebranded Package/Main Activity Name
com.motorolasolutions.enterprisehomescreen
com.symbol.enterprisehomescreen
com.motorolasolutions.enterprisehomescreen.HomeScreenActivity
com.symbol.enterprisehomescreen.HomeScreenActivity
Configuration File
The existing EHS configuration (stored in the enterprisehomescreen.xml file) is fully compatible with the
rebranded EHS. There is no need to make any modifications.
API Intents
The existing EHS API intents are still supported for backward compatibility but they are being
deprecated. It is strongly recommended that applications are modified to use the rebranded intents as
soon as possible:
Existing Intent Name
Rebranded Intent Name
com.motorolasolutions.enterprisehomescreen.actions.
MODIFY_KIOSK_MODE
com.symbol.enterprisehomescreen.actions.
MODIFY_KIOSK_MODE
For Mobile Device Management Solutions (MDMs)
MDM agents are applications as well, and as such must also be modified to reflect the rebranding issues
described here. Morover, an MDM agent may be required to manage a device both before and after
conversion. Both of our “Tier 1” MDM partners, SOTI and AirWatch, are building so-called “universal”
MDM Clients, which can run on both non-rebranded and rebranded devices. This “universal” agent can
be installed on devices before conversion, and upon conversion to the rebranded system, can continue
to function to manage the device.
For Additional Questions
Please refer to our developer Launchpad site ( http://developer.zebra.com ) for upgrade guidance that
applies to your specific scenarios
Appendix 3: Why are these Changes Occurring Now?
Some of the changes that occur when upgrading a Zebra mobile computer from Jelly Bean to Kit Kat are
the direct result of changes in the Android OS itself, and some are the result of choices made by Zebra in
response to the problems and opportunities presented by the changes in Android.
Further, some changes in permissions in “enterprise” storage are the result of Zebra’s desire to offer
GMS versions (as well as our “Professional” versions) of many devices. This decision has brought about
the need to ensure that all our devices (not just those with GMS) pass the Android CTS, defined by
Google.
Still other changes (the programming-level “namespace” changes) are the result of the legal need to
update corporate monikers to reflect Zebra’s ownership and to discontinue the use of names to which
Zebra was no longer legally entitled. That this happened at the same time as the changes forced by Kit
Kat is merely coincidence, but it does allow “getting it all done at once”, at a well-defined boundary –
the Kit Kat upgrade.
Changes in Android's Storage Access Rules, Beginning with Kit Kat
Beginning with Kit Kat, Android finally recognizes that a device may have more than one external
storage volume. OEMs have been providing devices with built-in, or "emulated" memory cards for some
time. And many Android devices allow multiple "external storage volumes". But until Android Kit Kat,
the OS's API calls relating to external storage only returned information about ONE external storage
volume, and completely ignored the others. Application developers who wished to use any other
external storage volume were obliged to hard code a path, or attempt to discover available paths, which
were all non-standard and could make the application dependent on a particular configuration or
device. With Kit Kat, the Android OS recognizes multiple external storage volumes by providing APIs that
return information about ALL the device's external storage volumes.
But Kit Kat also introduces some new and more restrictive rules for granting applications access to files
on external storage volumes. Applications that are not "ready" for the changes to file access may find
that they may no longer have full access to files that they created, and may malfunction after an
upgrade of the OS to Kit Kat.
Changes by Zebra in Response to Changes in Android External Storage
Prior to Kit Kat, Zebra device development teams and other OEMs found their own ways of dealing with
the lack of API support for multiple external storage volumes. Application developers often chose to
hard-code paths to external storage volumes, which could produce unwanted dependency on a
particular combination of device and configuration. In some cases, it could also make an application
dependent on how a particular device handled the presence or lack of an SD card in a slot.
With Kit Kat's new APIs, and with the differences in file access rules between Primary and Secondary
volumes imposed by Kit Kat, comes an both an opportunity for application developers to reduce
unwanted device dependency by utilizing the new multi-volume APIs to eliminate hard-coded paths, and
the need for OEMs to make an important design choice - the choice of which external storage volume
will be designated as "Primary".
Zebra has now chosen a consistent design for external storage volumes. Like many other OEMs, we have
decided to designate as Primary the always-present, built-in external storage volume rather than the
removable memory card which may or may not be present, and which in some devices may not even be
supported.
Changes to Zebra “Enterprise” Storage Permissions
Co-operating with Google enables Zebra to offer versions of our mobile device that include and support
Google Mobile Services (GMS). In order to remain compliant with Google’s design policies, changes are
being made in “enterprise” storage and /data/tmp to achieve a standard configuration across all our
Android devices.
The /data/tmp folder was never supposed to be used by non-system applications on previous builds, but
its permissions may have allowed it to be used. Starting with the KK build, /data/tmp will be unusable by
non-system applications.
Previous builds of Zebra devices allowed applications to see the files and folders under the /enterprise
folder. Beginning with Kit Kat, the permissions on /enterprise will not allow this, though they will allow
/enterprise to be used in specifying paths like /enterprise/usr. Permissions on /enterprise/usr will
remain open (world readable and world writeable) so that non-system applications may store their data
there and be sure it will persist across an Enterprise Reset. This is very much as before, but there is an
important change in this area – the system will no longer “open up” the permissions on files here after
an Enterprise Reset – so each application will need to be sure that all its files and folders are set to world
readable/world writeable by setting permissions on all its files and folders under /enterprise/usr to
“777”. Failure to do this will result in an application NOT being able to regain control of its files after an
Enterprise Reset.
Also note that /enterprise (like /data and every folder with “771” permission string) will be a “dead end”
for non-system apps that “browse down”, or descend the file tree one step at a time, as some File
Browsers to. Only “system” apps can see beyond such a “dead end”. If a file browser allows entry of a
destination, entering /enterprise/usr will result in being able to browse that folder and its subfolders.
.