Forum Discussion
[Feedback] App installs: share your experiences & suggestions
Hello everyone,
Our team is always interested to hear your insights around the current employee experience on managed Android devices and profiles (Work Profile). One specific area of focus is the application installation experience, particularly for apps installs that happen while the device is in use (not part of initial setup).
The installation experience can vary depending on a variety of factors - the device model and Android version, configuration of your EMM’s DPC client, management mode of the device (fully managed vs. Work Profile), the permissions required by the app, the source of installation, permission policies, etc.
Based on your setup, it would be fantastic to hear some of your user experiences and what improvements you’d potentially like to see?
I know this is an interesting topic for many of you, so I'm looking forward to hearing your thoughts, feedback and having a good conversation.
Massive thanks in advance,
Lizzie
32 Replies
- MichelLevel 4.0: Ice Cream Sandwich4 months ago
Hi Lizzie,
A couple of things come to mind with regards to working with apps on android (smartphones and tablets for me):
- App version management
- This is now done within an MDM that supports version management (WS1, Knox Manage and more)
- It would be nice to have such a feature in MGP making it available to every managed device without waiting for an MDM to implement it, or not.
- Some apps require specific rights, causing Android to prompt the user for approval. In some cases, you just want to make the device work as expected without involving the end user. Prompts do not always appear, depending on the app, and end users might ignore them making the app not work properly
- I'm aware that this is expected behaviour due to privacy regulations. But on a fully managed or dedicated device, you could say that the end user is using a device work purposes only (in theory). I would rather see that I'm able to set all needed permissions for an app, and notify the user that some privacy related permissions are given to an app instead of asking the user to set it.
- LizzieGoogle Community Manager4 months ago
Thanks for this Michel, some great points here. I find the prompts particularly interesting, as I know this has come up before in the community for a range of use cases.
I think you make a good argument for the way prompts are shown on fully managed / dedicated devices. Just to check when you say 'I'm able to set all needed permissions for an app, and notify the user that some privacy related permissions are given' - how would you envision this notification to happen? ie. a pop-up message when they first use the app or in another form?
Thanks again. 😀
Lizzie
- MichelLevel 4.0: Ice Cream Sandwich4 months ago
Since not all apps are opened on a device (monitoring apps for example), I think a notification in the notification bar would work best. Except for devices without notification bar. 😅
- mattdermodyLevel 3.0: Honeycomb4 months ago
The lack of proper version control in Managed Play continues to be one of the primary barriers to adoption for fully managed device use cases. I ultimately need to be able to control what version of an app is installed on a given group of devices and have precise control over the timing of upgrades and the ability to roll back as needed. MGP currently doesn't provide any of those mechanisms (precise timing, rollback, version control) so I can't realistically adopt it for mission critical device deployments. Instead I have to rely on direct APK installs through custom DPC based EMMs and avoid AMAPI based EMMs entirely. Until this feature gap is closed we won't be able to consider any AMAPI based solutions for line of business device deployments.
Also completely agree on your point around privacy prompts on company owned devices. It's completely nonsensical for these prompts to be displayed on a line of business devices like a POS register or an inventory device in a warehouse that are ultimately configured by an IT team and also shared across many users. What is the point of having a user granted permission prompt when the end user themselves are never being faced with these prompts (devices configured ahead of time). This extends into the increasingly painful setup wizard permission prompts that make no sense in the fully managed device space. The person manually accepting these prompts is not the ultimate end user of the device so what even is the point? We need to be able to blanket accept given permissions and prompts at an enterprise level for corporate owned shared line of business devices.- LizzieGoogle Community Manager4 months ago
Hey mattdermody,
I hope you are doing ok. Thanks for sharing your thoughts on this, I knew you'd have some feedback on this.
Your points on the prompts, as I said to Michel, I think this makes a lot of sense. Regarding the 'blanket accept given permission', as some of the acceptance is regarding privacy and in place to protect the end user, are you saying for fully managed devices would you have this display say once to the user when they get given the device (and start using it) or are you thinking at another time? And if new apps coming on have a more heavy level of permissions needed, would you like that to be blanketed into the one time prompt at setup? Feel free to correct me if I've misunderstood here. 🙂
Thanks again,
Lizzie
- App version management
- remlapLevel 1.6: Donut4 months ago
Hi Lizzie,
I believe that a truly "fully managed device" should require no hands-on setup by the user.
The current process often requires employees to manually accept special permissions and other requirements after the device has completed it's Android Enterprise provisioning setup. This can include granting permissions to settings like accessibility, alarms and reminders, and appear on top. To make the process smoother and reduce employee effort, we should automate the acceptance of these permissions.
When devices need to be reset in the field, a common troubleshooting step for managed devices - we often rely on employees to handle the provisioning process again. This can be confusing and lead to errors, especially for those unfamiliar with the setup.
I'd like to see an update to the current limitation of only six apps (one kiosk, five others) being set as required for setup. Many companies have more than six prerequisite applications, so increasing this limit would be a significant improvement.
Additionally, the ability to roll forward and roll back applications would be incredibly helpful for managing app updates. This would allow us to quickly revert to a stable version if a new update causes issues, ensuring maximum device uptime.
- melanieGoogle Team4 months ago
Thanks for this great feedback!
I agree, there's strong difference in requirements between devices setup by an IT Admin (or whiteglove-service 3rd party...) in advance vs. setup by the employee intended to use the device.Re: maximum apps limit - let me look into this. Who is your EMM?
- remlapLevel 1.6: Donut4 months ago
The limitation is based on the AMAPI's REQUIRED_FOR_SETUP, and not limited to which EMM we're using. See this policy here:
https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#installtype
- MoombasLevel 4.4: KitKat4 months ago
I think, from what i read, you do the app providing the wrong way.
You provide apps the normal way after the enrollment is done and then you can use for example https://developers.google.com/android/management/reference/rest/v1/enterprises.policies?hl=de#installtype:~:text=Anwendungen%20delegiert%20werden.-,BLOCK_UNINSTALL,-Gew%C3%A4hrt%20Zugriff%20auf to block the unintallation if needed (without a limit of apps being provided) which i see as the only reason for using your option mentioned before.
- Alex_MucLevel 3.0: Honeycomb4 months ago
I agree with the others, especially on those points:
- App versions can be managed per MDM
- App-Op Permissions can be allowed for Work Managed per policy
We primarily use COPE devices and prohibit sideloading, as this is one of the highest security risks. A few users are bothered by this because they would like to install apps from the F-Droid store in a private context.
At the end of July, a “southern German” newspaper wrote about european (/open source) solutions. Almost half of the article was about Google Play (vs. F-Droid) and Android (vs. e/OS). Unfortunately, the article treated “open source / data protection” as synonymous with “security” and made some interesting statements like "Safer app store: F-Droid instead of Google Play". When people read something like this, they tend to believe the statements at first and don't question them.Currently, sideloading can only be generally allowed or prohibited. If you wanted to offer alternative app stores, you would have to be able to whitelist individual apps for sideloading/app installations. However, this still presents a chicken-and-egg dilemma, because the store itself must first be installed via sideloading. This installation in particular must be trustworthy, otherwise someone could slip in a manipulated app and cause a lot of damage.
I can't think of a good solution, but we keep getting questions about the F-Droid store. I get why people want open source apps without tracking or ads. But for security reasons, we always have to say no to these requests.
- MoombasLevel 4.4: KitKat4 months ago
I think i mentioned this already several times (always in case of COPE or fully managed!):
We need one of the following things:
- Possibility to grab the original apk files from play store, to use app deployment from MDM side (if available) to have full version control (ofc only for free apps, paid apps must be then requested from the developer).
- Recommended: To get full version control via managed play store
- Choose update option per app:
- Always update (always to latest version)
- Install/stay on x.x.x (available versions need to be read out from playstore), needs to be changed if you choose a new one
- Never update (stays on the version intially installed)
- Permissions set per app (not asked for yet from my side):
- Show all permissions in an option available on the system
- Already tick the ones the app would request
- Possibility to tick permissions not asked by the app but you want to grant
- Possibility to untick permissions asked by the app but you don't want to grant
- Choose update option per app:
Or even both to have the best experience...
- RakibLevel 2.3: Gingerbread4 months ago
Whats possible in our MDMs for Android Enterprise:
Intune: Only possible to install apps from managed google play store
WS1: Install from google play store and upload apk-file from console.
Issue is Google Managed store requires an unique appid even for private apps, can this restriction be removed for private apps. Thanks!
Pretty please 😇- MoombasLevel 4.4: KitKat4 months ago
Pretty sure it's not possible on the way the playstore is working and yes, i was thinking about that a long time ago but came to the decision that if you use play store functionalities (where the private one is part of), it must work like this because that's the identifier (like in a DB) the playstore looks out for the app information like version and so on.
So if you would allow it, they get mixed up or need to be 2 completely seperate systems etc. where both doesn't sound good.
So, finally you need to use a MDM which can provide apk's directly, so having version control there (like WS1 and Mobicontrol or others) or you need the app developers to create an apk with a bundleID unique for you like "their.bundleID.yourCompany" so you can make use of the private play store.
But again, would way more likely have a full version control inside of MGP or even the possibility to load apk's directly from playstore to provide them via the MDM (maybe isolate the download possibility to managed google playstore accounts and ofc only to free apps).
- RakibLevel 2.3: Gingerbread4 months ago
This is the section for asks and suggestion, I know it is not possible today. I feel that managed play store and public store store should not abide the same rules, just like versioning, reverting and other suggestions from this thread.
- weberdaLevel 2.2: Froyo3 months ago
We use COPE for almost all devices and what we often see is that app updates in the work profile are not successful because of these:
- App updates in personal profile are not automatically applied. Sometimes you have to guide users even to install all pending updates before you can complete the work profile app updates.
- App updates in work profiles are paused because there is a incompatible version of the same app installed in the personal profile. (I can remember the exact error text).
- steve_mdmLevel 1.5: Cupcake3 months ago
Bit late to the party, but here is my input.
Some background: We have an intentionally simplistic MDM for use in high security environments were external connectivity is sporadic at best and often on air-gapped networks. As such installation of apps via the Play store is just not an option. We are currently enhancing our MDM with "app store" like functionality for use in closed environments on fully managed (DO) devices only.
This has actually been going quite well until Friday when Google Play Protect suddenly started blocking our DPC (but that is in another thread).
The main thing I would have liked to see was an ability to delegate silent app installs/uninstalls to a dedicated app rather than have to have it embedded within the DPC itself. It's not critical, but it would be better separation of concerns.
Related Content
- 2 months ago