Best practices for internal app code obfuscation and version uploads

Application versions

When determining the version of an uploaded application, AirWatch will parse the versionName field.  AirWatch will parse the first three specified integers, and use periods as a delimited.  Any non-integer values are stored as the integer 0.

For example, the versionName "5.0.3.1" will be stored in AirWatch with the following values:

  • 1: 5
  • 2: 0
  • 3: 3

In AirWatch the version of this internal application will be "5.0.3."  Note that the final value is truncated.

Additionally, the versionName "4.0.a.1" will be stored in AirWatch with the fllowing values:

  • 1: 4
  • 2: 0
  • 3: 0

In AirWatch the version of this internal application wil be "4.0.0."  Note that the "a" is converted to the integer 0 and the final value is truncated.

APK obfuscation

If you are using a tool to obfuscate the resources in your application such as DexGuard, or ProGuard, there are some additionally requirements to ensure that the application is properly handled by the AirWatch console.  In particular, ensure that any filenames explicitly written in the code are not obfuscated.  Additionally, ensure that the Manifest.xml file is not obfuscated.  

An example of supported parameters used when obfuscating an app with Dexguard are given below:

 

# Airwatch requires the AndroidManifest to NOT be obfuscated in order to parse for certain fields  

-keepresourcexmlattributenames manifest/**

# Airwatch requires that filenames are not obfuscated

-resourcefilenameobfuscationdictionary empty.txt

# With the above setting, Dexguard no longer obfuscates the filenames so that they are un-readable, but it does obfuscate
/ shrink them so that they contain duplicate/mixed-case filenames in the form of a.xml and A.xml, which is not fully supported by AirWatch. The below setting prevents this type of mixed case duplicate filenames.

-dontusemixedcaseclassnames
Have more questions? Submit a request

0 Comments

Article is closed for comments.