User Profile
mattdermody
Level 2.3: Gingerbread
Joined 2 years ago
User Widgets
Contributions
Custom app installation with AMAPI
Thanks to the keen eye of jasonbayton for spotting this update in the documentation: https://developers.google.com/android/management/manage-custom-apps The lack of this feature has been a key reason I've avoided any AMAPI based EMM (looking at you Intune!) for fully managed device deployments. This is certainly a welcome enhancement to AMAPI and one that I'm honestly surprised Google delivered on. I think I can finally see the writing on the wall that Custom DPC will eventually now die given that AMAPI is finally catching up. I still need file system push and pull for it to truly be a replacement but this is a major step in the right direction. What are the community thoughts on the matter?Re: Google Play update: new layer of security coming in 2026
Echoing what jasonbayton has already said, this is incredible news. Especially point #2: 2. Applications installed by EMM Device Policy Controllers (DPCs) will be exempt from requiring developer verification indefinitely. (For example, apps installed via Workspace ONE Intelligent Hub, Intune Company Portal, SOTI MobiControl, etc.)Re: [Announcement] Launching Android Enterprise Insiders & Registration
VERY Interested. Not sure if it matters but I have ~150 Org Ids across all of the different environments I manage. I can put an Org Id from one of my test EMM environments but I don't think that's going to be representative of the scale of environments that I interact with.Re: Android Developer Verification Requirements in AE
I would love for the same blanket exception that was applied to GPP to also be applied in this circumstance for apps installed on Fully Managed devices by a Device Owner DPC. In that situation an enterprise admin is electing to install a business app on assets owned by the same enterprise they do not need or want Google sitting in the middle of that dictating what they are or are not allowed to install on their own devices.Re: Disable random mac address during EMM enrollment
I am happy to hear this is acknowledged as an issue and it is being reviewed as a potential future DPC extra. With that being said, even with that possibly getting taken up, I suspect an actual resolution for AFahmy to be far away and likely out of reach on the current devices. I could be mistaken about this but introducing a new DPC extra that the device recognizes and leverages during the SUW would likely require an upgrade to the device OS first. I would therefore not get your hopes up about getting a solve for this particular batch of devices that is being deployed. It sounds like this issue might be resolved in the future on future OS versions through a DPC extra during the SUW but you may not have any options on your current devices. If it were me I would be exploring alternative staging networks for the equipment that are not MAC filtered / allow random MACs. If your OEM has an OEMConfig that supports MAC randomization disablement you can then apply that after the initial staging and enrollment process. You otherwise are going to be hard pressed to have MAC randomization disabled during that initial setup process when the device is first connected to the network.Re: [Feedback] App installs: share your experiences & suggestions
Rakib this brings up an interesting thought. With Google potentially being forced into opening up to 3rd party app stores as a result of their ongoing Epic court case I wonder if we could even see the advent of a new Enterprise app store completely separate from Google Play. In fact, most EMM providers could look to launch their own version of an app store depending on how this plays out. Come to think of it, if Android is opened up to 3rd party app stores I may even consider building out a custom app store for just one app that I manage. Instead of installing my app my end customers would install my app store and then I'd be able to manage the availability of new versions of apps and different test tracks from there. Hmmm 🤔.Re: [Feedback] App installs: share your experiences & suggestions
Completely agree on these points. I represent both a software company developing line-of-business apps as well as a device management and support business. Because we deal with mission critical mobile app deployments we can't rely on Public Play for app deployments because it doesn't offer proper version control for our end customers. That leads us to the path of test tracks in Private Play, but even that is unmanageable given certain limitations with the number of test Orgs you can associate with and the number of tracks certain MDMs like Intune can render and interact with. We are also completely unwilling to generate ~1500 unique compiles of our app for each individual customer and to generate those on the 2 week sprint cycles. That finally pushes us completely away from Managed Play (public or private) to the realm of direct app installs. This is in turn effectively eliminates all AMAPI aligned EMMS and narrows viable EMMS to just those that also offer direct APK installs like WS1, SOTI, and 42 Gears. This tends to ruffle feathers within IT organizations, especially those that don't grasp these nuances but do like the price tag of Intune. At the end of the day however the mission critical business apps are more important than the management tool used to manage the devices so we tend to win that argument. The MDM should work in support of the business functions that the device needs to perform, and not the other way around.Re: Share your deployment experiences with Android zero-touch enrollment
Yes "Zero Touch" Enrollment certainly would be more attractive it was closer to actual Zero touches for the end user stepping through the enrollment procedure. As long as Google is going to force manual interaction with multiple privacy prompt and permission oriented screens I will have to have IT personnel and not end users perform those interactions. With that in mind I personally am less comfortable, at least currently, with the idea of remote wiping a device to have it automatically re-enroll as it currently won't automatically re-enroll without end user interaction.Re: [Feedback] App installs: share your experiences & suggestions
The OEM proprietary methods are highly technical to accomplish and likely using workarounds that Google probably doesn't even official endorse. I'm worried about sharing more details for risk of Google closing those "vulnerabilities", which is the opposite effect of what I'm ultimately looking for. A similar situation is Google stepping in and stopping OEMs from automating their way through the Setup Wizard (SUW). We used to be able to bypass the SUW and skip straight to our OEM specific enrollment method and now are stuck manually tapping through numerous setup wizard prompts that slow down the process. How would I want the dangerous permissions to work in an ideal world? Any DO DPC installing apps should just be able to automatically silently grant those dangerous permissions. There simply should not be the idea of a runtime permission presented for any app for a shared line of business fully managed Android Enterprise device. It is otherwise ironic to continue to call it "Fully Managed" or "Device Owner" if we continue to give the end users some level of agency.Re: What security threats do you experience the most?
The biggest security threat or vulnerability we are exposed and actually affected by the most are the end users themselves. As a point of clarification I deal exclusively with enterprise line of business devices that are shared. Examples include inventory management devices in warehouses and retail stores, point of sale registers, kiosks, digital signage, etc. The end users leveraging these devices are often the biggest threat that we have to manage. There is a never ending battle to keep these end users off non-productive websites and apps like Youtube, Chrome, etc in order to keep them on task on on their business apps only. This is a constant struggle as these end users have a lot of time on their hands interacting with these devices in order to come up with creative workaround. Think for example a warehouse worker that might be interacting with their device 8-10 hours a day every single week. These users find ways to break out of lockdowns and access websites, apps, and settings that they shouldn't. One of the most frustrating examples is when there is some sort of privacy policy linked within an app that launches out to Chrome, or an in app webview with an editable URL bar. A classic example of this is the stock Calculator app. We provided end users access to this app for legitimate business reasons until we figured out they were accessing the privacy policy which was linking them out to Chrome which led them to get out to the internet. Ironically it was therefore Google itself making our devices more insecure and vulnerable to attack. Why a calculator needs a privacy policy is beyond me. Either way, I have dealt with countless weekly incidents of end users abusing their devices and working around restrictions. Far far more issues than the ones people seem to pay more attention to. The calls are coming from inside the house, so to speak.Re: [Feedback] App installs: share your experiences & suggestions
I dont think the end users should be prompted AT ALL for the devices that I'm referring to. A barcode scanning device shared across numerous shifts and end users without one dedicated end user should not prompt for privacy prompts or run time permissions. These should be able to be granted instead globally by the EMM. There are also android powered POS registers, customer facing displays, digital signage, kiosks, and other mission critical shared device uses where it does not make sense to have any end user view and accept privacy permission prompts. It makes even less sense to consider prompting every new user every time to accept these prompts. Imagine you're at a check out in a grocery store and you have to first accept Android privacy permission prompts before being able to proceed with your checkout. Google just doesnt seem to understand all of the use cases of their OS and are applying consumer grade protections to enterprise level devices as a result.Re: [Feedback] App installs: share your experiences & suggestions
Google has designated multiple permissions as "Dangerous" and transitioned them to Run time permissions that are prompted to the end user. Examples inlcude Manage External Storage, System Alert Window (overlay), Package Usage Stats, Notifications, etc. These permissions are often critical for business apps on DO managed devices to function and yet we have to trust and rely on end users to accept them. It makes no sense because the end users themselves likely will never see the prompt as an IT admin is likely granting them for them, or if they do see it they may inadvertently dismiss it as they don't even stop to read what they say. Thankfully some OEMs have built proprietary methods for silently granting these permissions that we leverage heavily, but it is still strange that a DO DPC doesn't have these controls.Re: [Feedback] App installs: share your experiences & suggestions
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.Re: Google Keyboard configuration Intune
Gboard offers Managed Configurations that can control a lot of the app behavior. I am however not entirely sure it can provide you with what you're looking for. I recommend you look through the available Managed Configurations for the app and experiment with what is available.Re: Share your deployment experiences with Android zero-touch enrollment
Yes I think the moral of the story here is that is there is no one sized fits all solution for enrollment of Android devices but thankfully Android Enterprise presents multiple valid options for enrollment. For rugged dedicated wifi only devices with built in scanners that go in for repair frequently, ZTE is not a good fit. QR based enrollment and/or a OEM provided method like StageNow, Enterprise Provisioner, etc are often better. As Michel as pointed out ZTE can however be a good fit for mobile phones with cellular data connections that are being shipped out directly to knowledge workers. For those type of end users it's not a particularly big deal that you're making them tap through numerous screens manually to get their device enrolled (remember its "Zero touch" for remote EMM admins, but many touches for the end user holding the device). It's also a bigger issue of having one of these remote users lose or have their corporate phone stolen. My problem is the marketing around ZTE makes it sound like the best thing since sliced bread but my experience with it has been less than stellar for my particular management use case. I often find myself having to convince companies away from this strong marketing when identifying an enrollment strategy for their warehouse and retail store devices.Re: Is there an alternative way to perform the same function as UpdateApplication on Android 15?
I don't think you realistically are going to be able to continue to offer silently self-updating mobile applications in the future. These updates are expected to be performed by an EMM tool and/or Managed Play moving forward. I do not think declaring your own (non EMM agent) application as DO or PO is an appropriate resolution to this problem. DO under AE operates very differently from DA with one of the core differentiators being their can be only one Device Owner on a device. You would not be able to rely on declaring such a permission given that many of your end clients devices will likely already be managed by a true EMM DPC with declared DO privilege. In addition, DO is something that has to be declared while a device is in a factory default state. You cannot install your app later and then declare DO permission as it would otherwise already be too late. Inflating your own Work Profile just for your own app and then declaring that app the PO of that Profile also doesn't seem to be a valid solution in my mind. I could be mistaken about that approach however since I'm less familiar with PO deployments.Re: Share your deployment experiences with Android zero-touch enrollment
I deal exclusively with corporate owned line of business devices and as a result I generally try to avoid ZTE as often as possible. I have many reasons for this. The “ZTE” name is meant to imply that the IT staff has Zero Touches to perform on the device because it is self guided and led by the end user. There is actually a ton of tapping and touching to perform. This idea was built for COPE style devices so that central IT staff could drop ship WWAN, scannerless devices directly to knowledge workers who then go through the enrollment process manually themselves. ZTE on ruggedized AEDO devices just pushes the manual configuration process to end users at a site and opens many opportunities for mis-taps and troubleshooting to be required by central staff. ZTE is designed for devices that DONT have an integrated scanner and DO have a constantly-connected network (LTE, WWAN, cell phones). A device with a scanner should leverage that scanner for quick enrollment without the overhead of an external portal. A device without a WWAN connection will still need WiFi connected before it can access the ZTE portal. ZTE: Zebra StageNow: Since WLAN devices are not connected, distributing ZTE devices to end-users or knowledge workers means you must provide them with the wireless security information since they would have to manually key it in themselves. This exposes a security vulnerability by having your wireless credentials exposed and shared to sites. Devices in warehouses and retail stores are damaged and sent in for repair frequently under repair contracts. In a warehouse with 500+ devices 5 or so of them might be shipped out every single day to a repair facility. These devices get factory reset and tested at the repair facility before shipping them out. These facilities require that the devices are deregistered from ZTE before sending them in so they can execute the repair process and their tests. This therefore introduces a huge bottleneck to repair processes because the warehouse supervisor shipping out repair devices is not generally going to be a ZTE admin and therefore a step has to be introduced in the process that slows everything down. https://supportcommunity.zebra.com/s/article/Deregister-from-Google-s-Android-Zero-touch-before-sending-to-Repair-depot https://supportcommunity.zebra.com/s/article/Deregister-a-Device-from-Android-Zero-Touch-Enrollment I also really do not like the idea of being dependent on a separate, Google service like a ZTE console and server just to get devices configured. There have been many documented cases of ZTE having issues which could derail device deployments for many days. I do not want to put myself into a position where I have to tell a CIO they can't go live in their warehouse today because Google's having ZTE issues. It's a dependency I don't want for mission critical device deployments. https://www.androidenterprise.community/t5/general-discussions/zero-touch-registration-is-not-available/td-p/1256/page/2 https://www.androidenterprise.community/t5/service-announcements/fix-available-toserror-responses-accessing-zero-touch-customer/ta-p/4041 Cross pollination is also a hilarious problem that only this sort of system would introduce. Device enrolled in different company | Android Enterprise and ChromeOS Customer Communities - 2303 It's easier to just avoid ZTE because the benefits do not outweigh these pain points. For mission critical Android Enterprise device deployments it is better to leverage the OEM specific staging tools or something more predictable and reliable like the QR enrollment method.
