Zebra Mobile Computing Rebranding FAQ

Robert Galvin -
7 MIN READ
28

1. Why does Zebra Technologies need to rebrand the Enterprise products acquired from Motorola Solutions?

 

Motorola Solutions’ Enterprise Business is now a part of Zebra Technologies. As such, Zebra cannot continue to use Enterprise-related material containing the Motorola Solutions brand. This transition will take us many months to fully complete, and the timing will be different by product family. We will continue to ship Motorola-branded products until stock is depleted. For many products, the rebranding process is well underway.

 

2. What changes are being made to meet the rebranding requirements?

        

To meet the requirements for rebranding, changes to both Zebra Hardware and Software products will be required. The Hardware changes will include rebadging as the Motorola logos are replaced with Symbol or Zebra logos and the Regulatory filings are transferred over to Symbol or Zebra Technologies. (The use of the Symbol logo is a temporary strategy that allows us to transition away from the Motorola Solutions brand quickly on Enterprise products in development.)  The new Zebra logo will begin appearing on rebranded and new products shortly.

 

The Software changes vary by product, and can be divided into 2 levels:

 

Level 1 – Includes splash screens, icons, Copyright notices and references to Motorola Solutions. These changes are cosmetic only and were specifically selected so as not to impact any device or application functionality, or customer operation. The current Zebra portfolio of Windows Mobile, Windows CE, and Android Jelly Bean products fall into this category, and no changes to any application software should be necessary.

 

Level 2 – Includes all changes from Level 1 plus:

        • Namespace used for APIs/Applications will be changed to Symbol.
        • Manufacturer Name returned to applications will be Zebra Technologies.

These additional changes will ONLY be made on Android Kit Kat products as they may potentially affect the operation of some software.

 

3. Which products are impacted by the rebranding?

 

All Enterprise-related products will receive Level 1 rebranding, unless a product has reached the end of its Life Cycle and has been identified for the standard Zebra End-of-Life process. All other products shipping with Android Kit Kat will receive Level 2 rebranding, EXCEPT for the initial release of the TC70 Enterprise device. Refer to Section 2 for clarification on the Level 1 and Level 2 rebranding changes.

 

4. How will the rebranding changes for Kit Kat impact applications that were written and tested for Jelly Bean devices?

 

A primary goal of the rebranding effort has been to minimize the impact to our customers and their business operations. Jelly Bean applications running on rebranded Jelly Bean devices should not be impacted, as the changes are mostly cosmetic. For Kit Kat devices it is expected that most applications will have little or no impact due to rebranding. However, each application should be tested for Kit Kat compatibility. The specific procedures that developers and system administrators should follow resulting from the Level 2 rebranding changes are identified in Section 5.

     

5. What steps do Software Developers and System Admins need to take as a result of the Level 2 rebranding changes?

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

As part of the transition from Motorola to Zebra, a number of components were rebranded. 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.     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:

 

Use the “android.os.Build.MANUFACTURER” field for determining if a device is Zebra branded. Rebranded devices are set to “Zebra Technologies” whereas Motorola devices are set to “Motorola Solutions”.

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 – A few deployments use Zebra supplied application specific tools and utilities to perform configuration of devices (for example, provisioning APKs). Although these tools and utilities are not being updated to include new features, they have been rebranded and support backwards compatibility. Customers using these utilities should request the updated versions for use on rebranded terminals from the same channel that the original APK was obtained.

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.


Additional specifics are provided below for the rebranded versions of the EMDK, DataWedge, and the EHS APK.

EMDK – Included in newer Device Operating System (OS) Images. The 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 – Included in Device OS Images

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_SOFTSCANTRIGGER

ACTION_SWITCHTOPROFILE

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.motorolasolutions.enterprisehomescreen.HomeScreenActivity

com.symbol.enterprisehomescreen

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 vendors are rebranding their agents to support our rebranded devices. Rebranded Kit Kat OS builds have rebranded MDM Clients already embedded in the OS. Those Clients are compatible with specific Agents that support rebranding.

 

Please refer to the Launchpad site (https://developer.zebra.com/community/android) for upgrade guidance that applies to your specific scenarios.

 

For Additional Questions

 

It is critical that we continue to serve our customers with the highest quality of service that defines our brand. Should you have questions regarding the rebranding process, please refer to the Launchpad site for guidance.

profile

Robert Galvin

Please Register or Login to post a reply

Replies