SOTI Pulse Logo

In-house app will not update on fully managed Android device

JK
James Knight

I cannot deploy an in-house app update to Android fully managed devices.

It has always been a challenge to deploy updates to Android devices on BYOD or COPE policies, but previously I've been able to install and update to fully managed devices without issues. Now I cannot.

This may have coincided with the upgrade to MobiControl 24 (which I did a couple of weeks ago), or it may be caused by an Android "security" update.  Usually I would upload a new package, and then change the package version in the profile, and all devices would be updated.  Now, the devices are reporting a failure to install the package.

I see this in the log:

Error message received from device - Failed to install application <app name> from package <app name.pcg>

Package "<app name>" version <ver> failed to install. File IO error on device. Check Storage/permissions.

Profile "<profile name>" version 9 failed to install, because all of its payloads cannot be installed.

I removed the profile from the device and tried using an app policy instead. I successfully installed the old version of the app (which had previously been installed via the profile), but attempting to update it resulted in error on the device "Install failed" (nothing in the server log).

Clicking the "upgrade" button in the App catalog results in "Install failed" again.

The last time I updated the app (a couple of weeks ago) I had similar problems which I worked around by constantly revoking and reinstalling profiles on each device (over 30), hoping that this might have been a transient niggle caused by the upgrade to MobiControl 24. But it seems not, as the new update is causing similar drama.

I've tried 2 different devices with the same result. I exported a log file for the test device and am seeing lots of instances of

2024-05-09 10:19:43.806|File saver - /data/user/0/net.soti.mobicontrol.androidwork/app_pkg/<packagename>.pcg.mrx.tmp|E|DO|[GenericSdCardManager] Invalid storage device path|java.lang.IllegalArgumentException: Failed to find storage device at /data/user/0/net.soti.mobicontrol.androidwork/app_pkg/<packagename>.pcg

Does anyone have any clues for me? Thanks!

In-house app update
a year ago
SOTI MobiControl
ANSWERS
RC
Raymond Chan Diamond Contributor
a year ago

What are the Android version(s) of the Android devices?

I believeyour problem is likely related to the updated scoped storage permission of the device firmware.      If so, the source code of the app may need to be modified and recompiled to get a new app binary.                 

JK
James Knight
a year ago

Thank you, Raymond.

My current test devices are on Android 13 (API level 33) and Android 10 (API level 29).

The log certainly points to a storage permission issue, but - since the app doesn't even get installed - is this more likely to be a MobiControl permission issue rather than an issue relating to the app itself?

Thanks again.

James

RC
Raymond Chan Diamond Contributor
a year ago

My customer previously had similar problem as yours with an app released by Microsoft on their AE work-managed mode devices.  The app could not be successfully installed/upgraded on devices running updated firmware with modified scope-storage permissions.   The problem was solved immediately without any change in the policy or MobiControl implementation, but just after Microsoft released a new binary version (possibly with obsolete permissions declaration in Manifest.xml & usage removed, unallowed work directory modified and other relevant changes in the source codes.) .

Also, another possibility of getting "file IO error" during app installation is the lack of sufficient free working memory space for completing the installation.  You can easily rule this possibility out by checking the amount of free memory on your two problematic devices.

RS
Rafael Schäfer
a year ago

We have seen a similar issue in the past, can the app being installed (instead of a direct upgrade) after you uninstall the old installed version?

We had a case with Soti open regarding this and the result was that there was something wrong with the app itself (not that long time ago)..

If that's the case, check (if it's your developed app) or contact the app vendor to check if their app was correctly deployed and build.

JK
James Knight
a year ago

Hi Rafael. This does sound similar.

When I upgraded to 3.0.6 of our app, all of the devices refused to upgrade. Revoking the profile or removing the app then allowed the app to be re-installed.

We prefer to use the profile method as it supports bundles, but this makes it close to impossible (as far as I can tell) to install on a BYOD or COPE work profile device.

All devices are now on 3.0.6 after a fresh install, so I've tried to upgrade to 3.0.7 using either method. Same problem - the app fails to install. Using the app policy method (so that I see the app in the app catalog), I click 'upgrade' and it says 'Install failed'.

If I remove 3.0.6 then I can install 3.0.7 from scratch. But if I remove 3.0.7 and re-install 3.0.6, it it refuses to upgrade again.

The bundle ID within the app is identical across all versions.

I'm unsure what to tell my developer, as I can't see what difference it would make that we are upgrading rather than installing afresh? Something to do with access to stored app data, perhaps? 

RS
Rafael Schäfer
a year ago

Have you tried to update from the previous version (where you have seen the issue the first time) to the now latest one?

Maybe the already installed one has the issue.

JK
James Knight
a year ago

As a test, my developer has created a new version 3.0.8, which is functionally and code identical to 3.0.7, other than the version number.

I deleted the app, and then installed 3.0.7 which was successful. And, this time, I was able to upgrade to 3.0.8.

I will do some further testing, attempting upgrades between various previous versions, to see where the problem might lie.

Thank you for your help.

RS
Rafael Schäfer
a year ago

Yeah i think i rmeember it was something regarding validation issue or so during deploying the apk (not a coding issue). So this could fit your findings.

MD
Matt Dermody Diamond Contributor
a year ago

Reasons why the app upgrade may fail when using a Package to upgrade an existing version of the same app:

  • The new App version is not compiled with a higher version number
  • The signing signature the developer used to sign the app changed across versions
  • A separate Package was used to build the new Package for the new version
  • Multiple versions of the Package are assigned simultaneously to the device.
  • Google Play Protect is blocking the install due to the targetSDK being too low or for other undisclosed reasons. 

Of these reasons my guess is that you may have been running into a GPP issue as it sounds like you were familiar with the process for upgrading this same app through SOTI Packages previously. If you had attempted to install the new APK manually on a test device you may have been able to see a GPP pop up warning telling you why the app install was being blocked. I have been encountering this more and more as of late as Google has tightened their restrictions. 

JK
James Knight
a year ago

Thanks Matt, that's helpful.

I suspect that, in this case, the issue was a new signing certificate.

Having carried out extensive testing of multiple scenarios, I could install any version from new, and I could upgrade from 1 -> 2 -> 3 but not 3 -> 4 or 4-> 5, but I could go from 5 -> 6. So something odd happened around version 4 and version 5.

I do know that GPP is causing issues on work profile devices, which compounds the issue of hidden notifications It seems that upgrading using a profile is next to impossible - the user has to know that the update is coming in the next 30 mins, and has to look out for a hidden notification, or MobiControl gives up after 30 mins. For app policies, the user at least has the option of pressing the 'upgrade' button in the app catalog, and then they must look for the hidden notifcation. In both cases, GPP sometimes jumps in but again that notification can be hidden.

I simply do not understand why Google think they should enforce GPP restrictions for in-house apps on company-owned devices.

Thanks again for your help.

MD
Matt Dermody Diamond Contributor
a year ago
JK
James Knight
a year ago

Thanks for posting that, Matt. I’ve replied as you suggested.

T
TLMOD@SOTI
a year ago

Hi James ,


Thanks for posting on SOTI pulse. Thanks Raymond, Matt and Rafael for responding to the post, your expertise and willingness to help are greatly appreciated!


Has your query been resolved? If not, or if you have any additional concerns, please don't hesitate to reach out. We are dedicated to providing assistance and support.


Also, if this post has helped you in solving your query, I would request you to mark the particular comment as "is solution", so that others may benefit from this information.


Kind Regards,

JK
James Knight
a year ago

I don't think I can say that the issue is resolved.

The next version (3.1.2) updated successfully on all devices from 3.0.8. But our developer cannot find any difference across the versions which would result in some version updates working, and others failing.

The contributions from everyone helped me to understand more of the process, and the possible issues. GPP is the most likely culprit, but we've no means of knowing due to the absence of useful information in the log.

Unfortunately I will have to wait until it happens again, and then used the knowledge gleaned above to do more detailed troubleshooting.

Thank you.

Similar Discussions