User Profile
jasonbayton
Level 4.1: Jelly Bean
Joined 3 years ago
Find my content on bayton.org
User Widgets
Contributions
Re: Is there any way to disable Google Play Protect (GPP) during QR code enrollment to avoid blocking an MDM app?
I appreciate you, thank you :) Custom DPC is.. maybe not prolific.. but popular and only growing as permissible use in AMAPI leads to fewer orgs being able to use it (or being approved to use it). I'm helping two organisations build their own custom DPC solution at the moment: one for AOSP, the other because they were rejected by the AMAPI gatekeepers, and can work without Play based on their use case. Neither would be partners in this case.. both may look to distribute on GMS devices now or in future. That doesn't even cover the nonstandard use cases like Acurast, or some open source projects I've seen use DO to set devices as dedicated kiosks (a music player comes to mind, but I might be wrong). No partners there. Thank you!Re: Is there any way to disable Google Play Protect (GPP) during QR code enrollment to avoid blocking an MDM app?
Sure, most of the complaints I've seen aren't coming from already-approved partners. Slipping in a help centre article and hoping folks stumble to it after whatever amount of damage this does to their business is unpleasant. There was no blog.google "tightening requirements on custom DPCs", no customer community announcement I saw.. so only those least likely to be impacted by this (existing partners) were proactively informed ahead of time I guess? If that's not the case my mistake, but Headwind here has struggled for most of the year after the change, I'm sure a pre-emptive Google play developer alert based on apps with the same flags it's using to block apps would have saved a lot of headaches (again if it did that then I'm mistaken). Otherwise much more could have been done without impacting people's livelihoods here. Blimey Google has given Device Admin vendors 7 years and counting to migrate, PlayEMM... 5 years and counting? This feels like an overnight change by comparisonRe: Is there any way to disable Google Play Protect (GPP) during QR code enrollment to avoid blocking an MDM app?
It looks like Google quietly introduced DPC whitelisting, but didn't do much due diligence to leave a well-established project like Headwind off the list. For anyone else looking for the reference to this: https://share.google/C0D4J0MrVSbc9tWLf It's unfortunate this seems to have been introduced quietly in the background and not the right way with a proper announcement and opportunity for vendors to take steps to become compliant ahead of time.[Day 4] Managed Google Domains: What, why, and how to upgrade
What is a Managed Google Domain? In Android Enterprise land, a Managed Google Domain refers to using a Google-managed organisation (like Cloud Identity or Google Workspace) to create and manage the connection to an EMM (the bind), it sits in contrast with Managed Google Play accounts, which uses a “personal” Gmail account to manage enterprise devices and apps. In practical terms, it means Android management is tied to an organisation’s work domain (e.g. @company.com), managed through the Google Admin console, rather than being tied to a single @gmail.com account. This approach unifies Android management with other Google services (Workspace, Chrome, etc.) under one organisational account, and is not only the default approach for all newly-binding organisations, but recommended by Google as an upgrade for all existing managed Google Play accounts enterprises due to the benefits it provides to IT admins and employees. Historically, organisations (even those with Google Workspace) used a managed Google Play Accounts setup - essentially registering Android Enterprise with a Gmail account - arguably said Gmail account could be created under a domain by using an existing email address, but this isn’t foolproof. The EMM (Enterprise Mobility Management solution) would then create generic managed Google Play accounts on each device for app distribution, account management, and so on. This legacy method worked, but it meant the entire Android Enterprise bind was owned by a personal account. It also means for devices there was no user identity, so things like automatic provisioning of the Google suite of applications with a managed account wouldn’t happen, and if a user was to add a managed account, behaviour around the app store, data sync, and more would become a challenge. Look familiar? Now, Google has introduced a better way. Why Google has (mostly) moved away from Gmail-based accounts Using a personal Gmail to manage enterprise devices has been convenient, but it poses security and management risks. For one, a Gmail-based enterprise bind is outside your corporate identity control - security teams cringe at the idea that the keys to your mobile fleet are held by an unmanaged personal account. There’s no way to enforce corporate security policies (no mandatory SSO, no corporate-managed 2FA or security keys) on a personal Google account. It also creates a single point of failure: if a Gmail owner leaves the company or loses access, recovering the account (and therefore control of all devices) can be difficult. Google’s solution is the Managed Google Domain - essentially migrating Android Enterprise enrolment to a proper Google organisation owned by the business. This shifts control from a personal account to corporate-owned credentials, immediately strengthening security. IT admins (plural, as now there can be several!) can log in with their work email and leverage enterprise-grade protections like multi-factor authentication (MFA), security keys, and single sign-on. In short, it “severs the tie” to the personal account and brings Android management under your company’s identity and policies. Equally important, Google is future-proofing Android Enterprise with this change. The new domain-led approach, rolled out in 2024, eliminates previous limitations. For example, historically one Google account could only bind to one EMM at a time. Now, once your domain is verified, you can actually bind multiple EMMs (or multiple instances of an EMM) to the same organisation - useful for testing a new EMM or running production and sandbox environments simultaneously. It also lays the groundwork for deeper integration with Google’s AI and cross-device features that rely on full Google accounts. How to upgrade to a Managed Google Domain For organisations currently on the older managed Google Play accounts bind, upgrading is straightforward and free. Google offers a one-way migration path from the Play Accounts enterprise to a managed domain enterprise. You can initiate it either via your EMM console’s Managed Google Play iframe or through an EMM provider’s implementation of the respective APIs: Via EMM Console (Play iframe): In your EMM console, navigate to the Managed Google Play area (for example, the app approval section). Many consoles now display an “Upgrade for free” banner or button at the top of the embedded Play iframe if your Android Enterprise is currently bound with a Gmail account. Clicking this starts the upgrade flow. You’ll be asked to sign in with the current owner account (the Gmail that was used originally), then provide a work email to act as the new admin account for the Google domain. If your organisation already has a Google Workspace or Cloud Identity domain, you can log in with a super admin of that domain to bind the enterprise to it. (Don’t worry - the Android Enterprise enrolment will belong to the domain itself, not that individual admin account.) If you don’t have an existing Google domain, you can create a new Managed Google Domain on the fly using your work email’s domain. For example, if you enter it@company.com, Google will set up a Cloud Identity domain for “company.com”. You’ll verify your email address and later have the option to perform full domain verification (to unlock all features, e.g authenticate with Google, ChromeOS management, and more. Via EMM API: Some EMMs may provide their own “upgrade” prompt or process using Google’s direct APIs. The steps are essentially the same - the EMM triggers the creation or linkage to a Managed Google Domain, and you supply a corporate email domain to either link or create the Google admin account. Speak to your EMM vendor for details on how to achieve this. Log in or create an account Authorise the migration Do a little shimmy, you’re done. After a successful upgrade, your Android Enterprise is now managed in the Google Admin console (under Devices > Mobile & endpoints, etc.). Notably, you should no longer use the old Play console for enterprise settings - those settings move into the Admin console and your EMM interface. The migration is again one-way; you cannot revert back to a Gmail-based setup, so double-check that chosen domain! The good news is that all your enrolled devices and approved apps remain intact - the change is largely on the backend linkage, and it does not unenrol devices or remove apps in your EMM console. Key Benefits of Using a Managed Google Domain: recapped Upgrading to a managed domain unlocks a range of benefits for both IT administrators and end users: Stronger Security & Admin Control: Admins log in with work email addresses and managed identities, not consumer Gmail. This means you can enforce your usual security policies (company SSO, MFA, password rules) on these accounts. Google specifically highlights that this allows enterprise-grade authentication - you can require admin logins to use multi-factor auth, hardware security keys, etc. Account recovery is also simplified (the domain super admin can reset passwords or reassign admin roles as needed). No more worrying about a single person “owning” the enterprise—ownership now belongs to the organisation. Single Sign-On (SSO) and Microsoft Integration: If your company uses Microsoft 365/Azure AD for identity, Google has made the integration seamless. The sign-up process can work directly with Microsoft 365 accounts, automatically tying in your external Azure AD identity as the IdP for the Google domain. This means your users (and admins) can authenticate with their Microsoft corporate credentials to access managed Google Play and other Google services, without you having to manually configure a SAML SSO federation. Google essentially removes the extra SSO setup step when you use a Microsoft-managed domain during the bind. Multiple EMMs and Flexibility: A Managed Google Domain allows binding multiple EMM instances to your single organisation ID. Practically, this means you could have, say, your primary EMM and a test EMM environment both managing subsets of devices under the same Google enterprise. Or, if you are transitioning between EMM vendors, you can connect the new EMM without unbinding the old one, then migrate gradually. This was impossible in the old Gmail-based model. Unified Admin Console & Google Services: Once on a managed domain, you gain access to the Google Admin console for device management and more. Beyond just Android management, this opens the door to centrally manage other Google products. For example, your team could explore using Google Workspace apps, Google Chrome management, or even new AI tools like Google Gemini on Android, all managed from one place. Better Employee Onboarding: With a managed domain, users can enrol their devices using their corporate credentials (email/password or SSO) rather than a special code or dummy account. This makes the provisioning experience more intuitive - they log in with their company email during setup, which configures the work profile/device. It also means if they already use Google Workspace, their apps and data can populate seamlessly. Legacy Managed Play Accounts can still be leveraged I mean this in two ways.. First, not every organisation may be ready to move to a Managed Google Domain immediately, and that’s OK. Google isn’t shutting down the old method yet. If you don’t have a Google domain or aren’t in a position to use one, you can continue using the managed Google Play Accounts approach with a Gmail admin account - your EMM will keep generating the necessary managed play accounts on devices as it always has. Nothing stops your Android Enterprise deployment from functioning, and Google will allow maintaining the legacy binding for now. Secondly, even if you were to migrate to a Managed Google Domain, some devices and use cases simply don’t suit user authentication/association. EMMs that support it should offer a personal use option for dedicated devices that will still provision a managed Google Play account for dedicated, userless devices. That use case isn’t going anywhere with this change. So, should you upgrade to a Managed Google Domain? If you can - absolutely: all the newest features and integrations are being built with Managed Google Domains in mind. So while you won’t be left in the cold if you stick with the old Gmail-based bind today, you’ll be missing out on security improvements and future capabilities going forward. Toodles, JasonRe: Intermittent QR Code Provisioning Failures with Identical Source Code
It's a bit of a slog, because Google choose to make it as difficult as possible, but on a failure there's an option in the Wizard (menu overflow) to send feedback. In that UI, the option to send system logs is available, and if you tap on the system logs link that shows it will take you to a window where you can scroll through the thousands of lines of logs the device generates. You may catch the issue there. Simplistic question, but are you using admin_signature_checksum or package_checksum in your QR payload? I'd assume admin as this is sporadic rather than guaranteed after any update. Do you have server logs from the host of the APK file? Is there any chance the network could be temperamental or inconsistently throwing a 4xx/5xx error? If you were to host the file elsewhere, like S3, R2, or some other public CDN, can you replicate the issue?Re: Custom DPC app being blocked by google play services
In lieu of a response from oianmol , as I understand it Play Protect is flagging applications with excessive permissions/reach on devices recently. If the DPC is not Google Play-hosted, it seems these prompts are more likely to crop up. DPC applications are permitted in Google Play, and it ensures the developer retains the right to the package name on a first-come, first-served basis. If it's an option to upload it, fill out the paperwork, and run through Play approval, I'd do so.Re: Android Enterprise coming to Android XR
😅 I can't keep making t-shirts haha So it's not the full Android OS we were promised in the run up to XR releasing? We (the royal we) were expecting support for most APIs day-1 since it was purported to be full Android, akin to on devices. Holding back AE in its entirety suggests otherwiseRe: Work profile creation on OPPO A6 PRO
Shock horror, 5 minutes of poking and they gave up. As above - have you ever tried to set up a work profile before? Do you have app cloning enabled? I have a few troubleshooting steps you can try below, it's for a failed, partially successful enrolment, but for all I know with the info given it could be relevant https://bayton.org/android/android-enterprise-faq/enrolment-failed-delete-wp/
