Android versioning is incompatible with MEMDM

[wlthomson]

Describe the bug

Current Android app versioning logic violates MEMDM constraints for enterprise Android apps (taken from here):

Ensure that the app size doesn't exceed 1.5 GB. Further, it is recommended to upload only a signed APK. The existing APK and the updated version of the APK need to have the same signature but different version code and version name. Also, version code needs to be incremented for each new app version uploaded.

From android/app/build.gradle:

def (appVersion, provisional) = getAppVersion().tokenize('-rc')
def (major, minor, patch) = appVersion.tokenize('.')
def appVersionCode = ((major.toInteger() * 10000000) + (minor.toInteger() * 100000) + (patch.toInteger() * 100) + (provisional != null ? provisional.toInteger() : 99))

Basic idea seems to be a weighted sum of major, minor, patch and rc versions to concatenate them into a version string. AFAICS, this will work out such that each version increase will have a higher version code than any previous versions and also contain some semantic info on the major, minor, patch, rc versions. Since MEMDM is still throwing a wobbly, current theory is that MEMDM will update mobile on a device iff newApk.versionCode == oldApk.versionCode + 1.

To reproduce

Steps to reproduce the behavior:

1. Using MEMDM, attempt to update an existing version of Mobile with a new apk.
2. See error.

From @Gwalior-84:

Expected behaviour

No error when updating mobile on Android devices via MEMDM.

Proposed Solution

To be discussed.

Version and device info

• App version: N/A.
• Tablet model: N/A.
• OS version: Android.

Additional context

Issue raised by @Gwalior-84.

[wlthomson]

Will need to investigate this a bit more, but current thinking is that we might want to setup a process for building dedicated apks for MEMDM devices, i.e. group target devices by existing mobile version and build apks with version codes set explicitly for each target group: ./gradlew assembleRelease -PversionCode=X

[josh-griffin]

@wlthomson interesting. I wonder if you can still upload the APK to the device and remote in to the device to upgrade 'manually' (just to help with this specific case)

[Gwalior-84]

This is for the ~ 80 devices in the PNG system. Remoting in is not an option.

I take it that we can't put the apps on the Google Play store? MEMDM does have a nice feature where it regularly checks the Play store and pulls the latest version from there, and can be set to automatically deploy it to the devices. Or do we want to exercise more control? Anyway, even if we did that, we might get the same issue if MEMDM does the same version number check.

If it would be useful, we can actually ask MEMDM support what the problem really is - as the new number definitely looks higher than the old number!

[wlthomson]

the new number definitely looks higher than the old number!

From what I gather, MEMDM is requiring each upgrade to have a version code which is exactly 1 greater than the previous version code (so just being higher may not be sufficient).

Going to @Chris-Petty as I think he was more involved in the migration to MEMDM, so may have some experience with this.

[Chris-Petty]

the new number definitely looks higher than the old number!

From what I gather, MEMDM is requiring each upgrade to have a version code which is exactly 1 greater than the previous version code (so just being higher may not be sufficient).

Going to @Chris-Petty as I think he was more involved in the migration to MEMDM, so may have some experience with this.

Seems a bit crazy to me, if what you hypothesise is true, if we skipped legitimate versions when updating the APK (say from 5.0.1 to 5.0.4) it'd fail? Seems to me MEMDM should fix that pronto. I didn't test specifically this, should be a given!

[Gwalior-84]

False alarm.

I remembered that we have not been deploying the 'universal' installer, and that is the 'flavour' that I was trying to update to (because we are anticipating getting some mobile devices on that system that will not run the armeabi-v7a 'flavour').

I tried this again with the processor specific 'flavour' (mSupplyMobile-5_1_1-armeabi-v7a-release.apk), and it worked.

So, a problem we have is that there is currently nothing in MEMDM that indicates what particular 'flavour' is installed, and when you try to overwrite the processor specific 'flavour' with a different 'flavour', it throws this wobbly.

I made a point of adding a description while updating:

Problem is, I can't see this description anywhere in MEMDM :-( I will take this issue up with MEMDM.

[Gwalior-84]

OK, I chatted with the MEMDM people.

To see the description that we add to a particular App, we need to open the 'Action' ellipsis and select Modify app settings:

But our problem is that each 'flavour' of mSupply uses the same Bundle Identifier com.msupplymobile. MEMDM (and any other MDM?) will not allow two different apps to use the same Bundle Identifier.

Any chance we could use different Bundle Identifiers, something like?:

com.msupplymobile-arm64-v8a com.msupplymobile-armeabi-v7a com.msupplymobile-universal com.msupplymobile-x86 com.msupplymobile-x86_64 (isn't x86_64 an oxymoron?)

[Chris-Petty]

But our problem is that each 'flavour' of mSupply uses the same Bundle Identifier com.msupplymobile. MEMDM (and any other MDM?) will not allow two different apps to use the same Bundle Identifier.

Any chance we could use different Bundle Identifiers, something like?:

com.msupplymobile-arm64-v8a com.msupplymobile-armeabi-v7a com.msupplymobile-universal com.msupplymobile-x86 com.msupplymobile-x86_64 (isn't x86_64 an oxymoron?)

Nah x86 is the instruction set, 64 indicates being 64bit version (as opposed to 32bit).

I'd sign into MeMDM go deeper but still not yet on the org!

Can you explain how you're uploading mobile as type "Android Enterprise App"? Is it through our linked Android enterprise account? I'd have thought that there you'd be able to upload each platform's APK there (the device should grab which flavour it wants, as far as I understand normal playstore functionality)? At which point I'd hope that Manage Engine happily treats them as one.

[Gwalior-84]

One day we'll get you in to our MEMDM account @Chris-Petty !

MEMDM instructions on installing Enterprise apps are:

https://www.manageengine.com/mobile-device-management/help/app_management/mdm_creating_app_repository.html?andsilentapp#android_enterprise_apps

I tried to upload the Universal 'flavour' of mSupply Mobile separately, rather than upgrade the existing armeabi-v7a 'flavour' to the Universal 'flavour'. Alas, no. It seems that MEMDM will not allow two separate apps having the same bundle identifier and version No.

[Chris-Petty]

@Gwalior-84 I had similar problems setting up a customer recently. I still think first port of call is the chase MEMDM to support .aab (Android App Bundle) files as opposed to APK if they can. That'd allow one upload where devices download the parts they require (like the universal APK but smarter).

Alternatively, I think they do support using a managed play store (i.e. a private play store for your enterprise). We may be able to upload the .aab file there solving this issue and getting the benefits of that format at the same time. Would have to figure out if it's managed through our 1 super admin account, or if we set one up for each MEMDM customer (which would be some overhead, but better than current situation and would allow managing what version each customer is getting!).

[Gwalior-84]

You sound like you know what you are talking about @Chris-Petty . Are you able and willing to take this up with MEMDM? What are the barriers to publishing multiple 'flavours' to the Play store like TeamViewer has done?

[Chris-Petty]

There is an overhead to doing so that we don't want to manage, considering this issue has been untouched since August. Also note, from my understanding all those are actually separate apps with bespoke solutions for various device manufacturers, presumably 'cause each manufacturer puts their own tweaks on android. The separation we are dealing with is lower level than that, targeting particular CPU instruction sets.

E.g. there is one "Teamviewer Host" app that will be using .aab format including bundles for each CPU instruction set, not five separate apps (which would be unconventional as far as I know).