User Profile
mattdermody
Level 3.0: Honeycomb
Joined 2 years ago
User Widgets
Contributions
Re: GBoard - Suggestion Strip
I do not have a case open with the EMM as it seemed to be an issue with Gboard specifically. This was evidenced by the fact that it was working perfectly fine previously in Gboard and it wasn't until an automatic push from Google Play to a new version did the previously working managed setting break. The suggestion strip was disabled properly on prior versions of Gboard and only started appearing again when Gboard was updated. I have even force uninstalled the upgraded Gboard to an older version packaged with the device firmware (v12.x) and that properly restored the desired adherence to the managed config setting to disable the suggestion strips. All of this seems to point to a bug with the Gboard app specifically and not an issue with the EMM and it's ability to apply managed configurations as far as I'm concerned. The EMM is SOTI MobiControl if that helps. Magcho what are you seeing this in?9Views0likes1CommentRe: GBoard - Suggestion Strip
Emilie_B Have there been any updates? This is now being reported across multiple customer environments who are frustrated that Google would push out this regression break. We're hoping for a quick fix so we can avoid having to change keyboards to a different provider.12Views0likes1CommentRe: DPC Extras issues
You can persist pretty much anything in the Enterprise directory on Zebra devices including EMM agents using Custom DPC. With that in mind if was enrolling a Zebra device I wouldn't be considering ZTE anyway since "Zero Touch" is a misnomer and I can enroll devices in a much more streamlined manner with Zebra StageNow.24Views1like0CommentsRe: GBoard - Suggestion Strip
I can confirm I am seeing this issue across a range of Gboard versions. This list is not definitive but I have seen it affecting these versions so far 15.8.4.793526320 15.9.1.799068799 16.0.5.804347959 16.0.6.804347959 16.0.7.804347959 16.0.8.804347959 16.0.9.804347959 16.0.11.804347959 16.1.1.809934391 I can confirm that "Show suggestion strip" is disabled in Managed Configurations but it is showing as enabled still on the device itself under Gboard settings. If I manually disable it on the device the bar disappears as desired. There appears to be a bug affecting Gboard's Managed Configurations.47Views0likes8CommentsCustom 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.)150Views3likes1CommentRe: [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.263Views3likes0CommentsRe: 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.77Views0likes2CommentsRe: 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.4Views0likes0CommentsRe: [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 🤔.33Views0likes1CommentRe: [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.28Views0likes0CommentsRe: Share your deployment experiences with Android zero-touch enrollment
If Zero Touch was actually Zero Touch like it claims to be, then yes. It however is not and we would leave devices orphaned out on the field awaiting manual set up from an end user before re-enrollment occurs.6Views0likes0CommentsRe: 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.23Views1like3CommentsRe: [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.15Views1like0CommentsRe: 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.55Views3likes1Comment