12 deliveries of AE-mas (What shipped in Android Enterprise in 2025)
2025 was a big year for Android Enterprise. This was the year several long-missed features finally landed, Device Trust became a thing, zero-touch got a compliance and audit boost, provisioning saw a revamp, and the Android Management API quietly kept adding the sort of controls that make admins' lives easier. So, in the spirit of celebrating a strong year for the platform, here are 12 Features of AE-mas (let's not worry about the title.. I was strugglin'), in no particular order, chosen somewhat at random as - would you believe - the list could have been longer should I have chosen not to follow the 12 days of Christmas as the theme.. 12. APN overrides via AMAPI APN management finally arrived. In May 2025, AMAPI gained apnPolicy, allowing admins to define and enforce APNs directly through policy. This closes a long-standing gap for cellular deployments where “just set the APN” has historically been anything but. It's great to see this functionality pulled out of OEM config and into the AMAPI layer, giving admins access to on-device APIs that have been effectively off-limits for years. Read about APN here. 11. Developer verification for Android Developer verification isn't coming until next year, but we're talking about it already, and work is in progress to bring it to fruition now. Developer verification raises the bar for Play publishers by requiring stronger identity verification. For enterprise, it’s a supply-chain win: fewer convincing lookalikes, higher friction for malicious publishers, and a clearer answer when security teams ask “who made this app, exactly?”. There’s pushback in the community, there's a lot of misunderstandings about the requirements and ramifications, but hopefully as time goes on this will settle on both sides through further transparency and discussion. Organisations deploying private apps to their own tenants are currently exempt, but it remains a big change nonetheless, and organisations benefit from the wider boost in authenticity of apps and developers. I covered off more about developer approval here. 10. Device Trust from Android Enterprise This was the year Device Trust arrived. Device Trust enables real-time posture and integrity signals (Play Integrity verdicts, boot state, security patch recency, lock-screen presence, strong auth age, OS tamper signals) that can be evaluated continuously rather than only at enrolment, and on both managed and unmanaged devices. It's a huge boost for MAM-type deployments, security solutions, and allows traditionally EMM-dependent vendors the freedom to operate independently. This isn’t a small feature. It fundamentally changes how Android Enterprise fits into modern security architectures. I wrote more about Device Trust here. 9. Custom app management via AMAPI (CUSTOM install type) One of the most consequential releases of the year, perhaps even since AMAPI began half a decade ago. AMAPI introduced first-class support for installing and managing custom applications using installType: CUSTOM, backed by signing certificate validation (appSigningKeyFingerprints) and explicit install and uninstall commands. It allows organisations reliant on line-of-business (LOB) internal applications to ditch any and all wild-west sideloading for a policy-driven, verifiable deployment, which is exactly what enterprise actually needs. All without the need for uploading apps to Google Play. I wrote more about custom apps here. 8. Zero-touch portal audit logs and admin roles The zero-touch portal became auditable and permission-scoped in 2025. Google rolled out audit logs to the zero-touch customer portal, capturing all admin actions needed to ensure the platform is no longer a black hole of who did what. Alongside this came clearer admin role separation, reducing the blast radius of operational mistakes. For regulated environments, this turned zero-touch from a black box into something governance teams could actually trust. 7. Android 16 provisioning improvements One of the greatest improvements to the enrolment flow happened in 2025, and it was so long overdue! Android 16 brought a clear push toward more reliable setup flows, fewer steps, and the ability to update it on the fly, as opposed to being stuck adjusting it only on major version releases. I put out a video nearer the start of the year, while 16 was still in beta, which you can see on LinkedIn here. With this newer approach, Google is beginning to leave behind the old managed provisioning flows baked into AOSP, though they're still there as a fallback today. It'll be interesting to see how this evolves. 6. Application roles in Android Management API This was unexpected. Application Roles formalised entire classes of enterprise apps, including: COMPANION_APP KIOSK MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE SYSTEM_HEALTH_MONITORING Apps assigned these roles can be exempt from background execution limits, power management, suspension, and hibernation on modern Android versions, with user control restricted by default. This isn’t just about companion apps - it’s about enterprise software finally being treated as first-class by the OS, and adds much-needed flexibility with far less configuration and overhead. 5. Default application management policy Admins finally gained control over default apps. AMAPI added a policy allowing admins to define a prioritised list of default applications per app type (browser, dialler, etc), setting the first qualifying app as default and preventing user changes. For compliance-sensitive fleets - browsers, diallers, PDF viewers - this is the sort of boring control that saves hours. It's predominantly Android 16+, but there's a few that go back a few versions of Android. Read more about default applications here. 4. RCS archival RCS has long been the compliance blind spot for Android Enterprise fleets, with SMS/MMS archiving handled by legacy tools while RCS was left out in the cold. In December, Google release a supported way to archive RCS/SMS/MMS on fully managed devices, with Google Messages as the mandated client. Once those prerequisites are met, admins can configure Messages to forward message bodies, metadata, and attachments to a SIEM/service/archival tool on a schedule or trigger with no needed workarounds or limitations of legacy solutions. It’s - to reiterate - Google Messages only for now (OEM messaging apps remain out of scope unless they add their own support), but it gives regulated orgs a sanctioned retention path for rich messaging at last. It has been met with quite a bit of mixed feelings, and even more FUD. I go into more detail about RCS archiving here. 3. App functions and cross-profile controls Android 16 brought app-to-app interaction under policy control. New settings allow admins to govern whether apps can expose app functions, and whether personal-profile apps can invoke functions exposed by work-profile apps, bringing finer control to cross-profile linking scenarios. Niche, but powerful for when this functionality takes off in enterprise workflows. 2. Android App Bundle (AAB) support in the Managed Play iframe This finally removed a long-standing enterprise limitation. In March 2025, Android App Bundle uploads became supported in the Managed Google Play iframe. Private apps finally gained parity with public Play distribution, including split APK delivery and more efficient installs. I wrote more about AAB here. 1. Android’s accelerated platform release cadence The change that underpins everything above. Android is shifting toward more frequent platform releases, with Android 16 landing far earlier than usual and signalling a broader move away from a single annual cadence. Harder to track? Maybe. I'm having a lot more fun poking around the Android Canary builds looking for unreleased functionality than I do sleuthing around AOSP code, though! Better for shipping enterprise capability without waiting a full year? Also yes. Signing off Android Enterprise levelled up across the board in 2025. From trust and supply-chain integrity to app management and provisioning improvements, the team set the bar really high this year. Let's hope the momentum continues in 2026! Which of these made the biggest difference for you this year, and what are you hoping lands in 2026? Happy holidays and here’s to a wonderful New Year![Guide] First aid for bug reports
Hi! Mobile devices are quite complex and fast- changing. Errors sometimes sneak in and as a UEM administrator you often have to find a solution. If in doubt, the UEM manufacturer is the first point of contact, but if it is an app or OEM-specific error, a ticket to the right place can also speed up the solution. In addition, any support team will appreciate it if you look into the problem before creating a ticket, provide specific log files and perhaps even roughly narrow down the problem. But... How? The commands for logs and the sheer mass of log lines can be quite overwhelming! In this topic I would like to provide some information about logging for Android Enterprise, which will hopefully help some of you in the future. I will not cover all commands or segments in log files. If there is something that you think is important for logging, please feel free to add it. 😀 ADB - Android Debug Bridge Get the tools The ADB is a versatile command-line tool with which you can execute commands on a device. The adb and USB debugging on the mobile device are essential for detailed debugging. https://developer.android.com/tools/adb If you are not a developer, you do not need to install the entire Android Studio. The SDK Platform Tools are very useful and fully sufficient for logs. You can download the tools for Windows, Mac and Linux here: https://developer.android.com/tools/releases/platform-tools Prepare the device In order to access the device with the adb, “USB debugging” must be enabled. The setting can be found in the developer options, which are hidden by default. The build number must be tapped several times in the device settings until the message “You are now a developer!” appears. Now you can enable “USB debugging” in the developer options. The paths may vary depending on the OEM: Settings > About phone > (Software information) > Build number Settings > (System) > Developer Options > USB debugging Using the adb Check and select connected devices Navigate on your PC with the command line to the folder with the platform tools. With every adb command, the client checks whether the adb server process is running. If not, it will be started automatically. “adb devices” is useful as the first command. The adb server is started and already connected devices receive a query as to whether USB debugging should be trusted with this computer. PS C:\platform-tools> adb devices * daemon not running; starting now at tcp:5037 * daemon started successfully List of devices attached 3C261JEKB15011 unauthorized Trust the connection on the device: PS C:\platform-tools> adb devices List of devices attached 3C261JEKB15011 device You can use the -l option to display further device information. PS C:\platform-tools> adb devices -l List of devices attached 3C261JEKB15011 device product:akita model:Pixel_8a device:akita transport_id:1 If you need to connect multiple devices, you can use adb -s serialnumber to select a specific device for the command. This is not necessary if you have only connected one device. PS C:\platform-tools> adb -s 3C261JEKB15011 bugreport /data/user_de/0/com.android.shell/files/bugreports/bugrepo...le pulled, 0 skipped. 29.1 MB/s (13935432 bytes in 0.457s) Bug report copied to C:\platform-tools\bugreport-akita-AP4A.241205.013-2025-01-09-13-23-16.zip shell commands With adb shell you can execute commands on the device. You can find a more comprehensive overview of the commands here: https://developer.android.com/tools/adb#shellcommands device users With Android, features such as the Work Profile, Private Space or MultiUser functionality are separated using “User”. You can list which users are active on the device: PS C:\platform-tools> adb shell pm list users Users: UserInfo{0:Owner:4c13} running UserInfo{10:Work profile:1030} running UserInfo{11:Private space:1090} Android has multi-user support, where different people can use one device: https://developer.android.com/work/dpc/dedicated-devices/multiple-users This feature is optional for OEMs. For example, an OEM may have enabled multi-user for a tablet but disabled it for smartphones. The Work Profile is a special rule and does not fall under this limitation. Up to 3 additional users PS C:\platform-tools> adb shell pm get-max-users Maximum supported users: 4 No Multi-User support PS C:\platform-tools> adb shell pm get-max-users Maximum supported users: 1 list packages You can use adb shell pm list packages [options] filter to show the apps installed on the device and optionally filter them with options and text filters. Options: -f See associated file and file path -d Filter to only show disabled packages -e Filter to only show enabled packages -s Filter to only show system packages -3 Filter to only show third-party packages -i See the installer for the packages (e.g. com.android.vending = PlayStore) --user user_id The user space to query. Examples: Show non-system apps (/ manually installed) in Private Space PS C:\platform-tools> adb shell pm list packages -3 --user 11 package:org.bayton.packagesearch package:de.heise.android.heiseonlineapp Check whether an app has been sideloaded in the personal space PS C:\platform-tools> adb shell pm list packages -3 --user 0 -i package:com.airwatch.androidagent installer=com.android.vending package:com.maxrave.simpmusic installer=com.google.android.packageinstaller package:com.google.android.keep installer=com.android.vending Show the full path of system apps that have “manager” in their name “priv-app” in the file path is an indicator that the app has privileged permissions. https://source.android.com/docs/core/permissions/perms-allowlist PS C:\platform-tools> adb shell pm list packages -s -f manager package:/system_ext/priv-app/StorageManagerGoogle/StorageManagerGoogle.apk=com.google.android.storagemanager package:/product/overlay/CompanionDeviceManager__nosdcard__auto_generated_characteristics_rro.apk=com.android.companiondevicemanager.auto_generated_characteristics_rro package:/product/overlay/StorageManagerGoogle__akita__auto_generated_rro_product.apk=com.google.android.storagemanager.auto_generated_rro_product__ package:/system_ext/priv-app/ConnectivityThermalPowerManager/ConnectivityThermalPowerManager.apk=com.google.android.connectivitythermalpowermanager package:/system/app/CompanionDeviceManager/CompanionDeviceManager.apk=com.android.companiondevicemanager package:/vendor/overlay/StorageManagerGoogle__akita__auto_generated_rro_vendor.apk=com.google.android.storagemanager.auto_generated_rro_vendor__ package:/system/priv-app/CredentialManager/CredentialManager.apk=com.android.credentialmanager Screen recordings You can take a screenshot or video via adb and then copy it to your computer. With high display resolutions, the resolution and bit rate should be reasonably reduced for video recordings so that the recordings do not become too large. Take and transfer a screenshot with adb shell screencap filename and adb pull path/file. PS C:\platform-tools> adb shell screencap /sdcard/screenshot.png | adb pull /sdcard/screenshot.png /sdcard/screenshot.png: 1 file pulled, 0 skipped. 31.3 MB/s (1760513 bytes in 0.054s) Videos can be recorded with adb shell screenrecord [options] filename. Options: --size widthxheight Define video size. (Default = display resolution) --bit-rate rate Set the video bit rate for the video in megabits/second. (Default = 20Mbps) --time-limit seconds Set the maximum recording time up to maximum of 180 seconds --verbose Display log information on the command-line screen. Example for half display resolution, 6Mbps and the display of log information PS C:\platform-tools> adb shell screenrecord --size 540x1200 --bit-rate 6000000 --verbose /sdcard/video.mp4 Display is 1080x2400 @60.00fps (orientation=ROTATION_0), layerStack=0 Configuring recorder for 540x1200 video/avc at 6.00Mbps Content area is 540x1200 at offset x=0 y=0 PS C:\platform-tools> adb pull /sdcard/video.mp4 /sdcard/video.mp4: 1 file pulled, 0 skipped. 3.2 MB/s (20353 bytes in 0.006s) Bug Report The bug report is a collection of various system services and logs. This report shows the status of the device quite comprehensively and is my first port of call when there are problems with managed devices. You should create the bug report as soon as the error has been reproduced. Often only the last 15 minutes are saved in the log buffer. The bug report contains several files, but the most interesting is a text file, which can quickly get 100MB in size and has over a million lines of content. As a rule, the text file begins with “bugreport” (or sometimes “dumpstate”) and ends with the creation date of the report. Generate bug report via adb and save it on the PC: PS C:\platform-tools> adb bugreport /data/user_de/0/com.android.shell/files/bugreports/bugreport-akita-AP4A.24120...-10-57-21.zip: 1 file pulled, 0 skipped. 25.2 MB/s (15330123 bytes in 0.581s) Bug report copied to C:\platform-tools\bugreport-akita-AP4A.241205.013-2025-01-10-10-57-21.zip A bug report can also be started manually in the developer options on the device. You can use the adb to search for bug reports on the device and copy them specifically from the device. PS C:\platform-tools> adb shell ls /bugreports/ bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06-dumpstate_log-5164.txt bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06.zip bugreport-akita-AP4A.241205.013-2025-01-09-13-23-16-dumpstate_log-31790.txt bugreport-akita-AP4A.241205.013-2025-01-09-13-23-16.zip bugreport-akita-AP4A.241205.013-2025-01-10-10-57-21-dumpstate_log-5743.txt bugreport-akita-AP4A.241205.013-2025-01-10-10-57-21.zip dumpstate-stats.txt PS C:\platform-tools> adb pull /bugreports/bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06.zip /bugreports/bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06.zip: 1 file pulled, 0 skipped. 29.1 MB/s (15931073 bytes in 0.521s) For Samsung devices, you can also generate extensive logs from the device using SysDump. This includes the bug report and even more logs, some of which are OEM-specific: https://docs.samsungknox.com/admin/knox-platform-for-enterprise/troubleshoot/get-device-logs/ logcat If you have problems with a specific app and no diagnostic data can be sent from the app itself, the logcat log will help you. Although logcat logs are also available in the bug report, experience has shown that some verbose and info logs from individual apps are not available there. With a bug report and a separately recorded logcat, you are very well prepared for troubleshooting. The default parameters for logcat are usually sufficient. PS C:\platform-tools> adb logcat > logcat.txt PS C:\platform-tools> adb logcat -v threadtime -b main -b system -b crash *:V > logcat.txt The two commands should provide the same output. By default, you already get a good output format, relevant buffers and everything from verbose logs upwards. -v threadtime -v Defines the output format. threadtime = Date, Time, Priority, Tag, PID, TID, message -b main -b system -b crash There are different log buffers for log messages. main,system,crash are default. There are radio,events,main,system,crash and all. *:V All logs with verbose or higher are displayed An example in which the events are displayed in the command line, color-coded from the debug level upwards for a specific PID (ProcessID) PS C:\platform-tools> adb logcat -v color --pid=16095 *:D Depending on your needs, you can experiment with logcat and read more in the official documentation. https://developer.android.com/tools/logcat Find your way through the bug report The bug report usually has over a million lines and is therefore not something you can simply scroll back and forth through manually. It is helpful if you know the rough structure and know what to look for. The bug report has three main sections: dumpstate dumpsys logcat Logcat Log Level Android has the following log levels: V Verbose (lowest priority) D Debug I Info W Warning E Error F Fatal S Silent (highest priority, never used for output) While verbose logs are intended to help you understand the functionality of apps, warnings and errors indicate a problem. However, some errors can often be ignored. If, for example, you have problems with apps that are terminated unexpectedly by the operating system, you will quickly find suitable logs in the bug report. This is because fatal exceptions occur rather rare. There is a noticeable backtrace in the logs, especially when apps are terminated by the OS. https://source.android.com/docs/core/tests/debug/native-crash The Logcat uses the buffers crash, system and main by default. You can jump to the respective one by jumping to “beginning of buffername”. Without having gone deep into troubleshooting, you may already encounter relevant logs at the “beginning of crash” that have recorded the problem. You will find logs for processes that do not belong to the OS under “beginning of main”. --------- beginning of crash 07-14 22:22:03.272 +0000 22979 23472 E AndroidRuntime: FATAL EXCEPTION: Analytics-HighPri-Proc 07-14 22:22:03.272 +0000 22979 23472 E AndroidRuntime: Process: com.facebook.appmanager, PID: 22979 --------- beginning of system 07-31 10:39:57.225 +0000 1220 1750 W ActivityManager: Slow operation: 90ms so far, now at startProcess: done updating battery stats 07-31 10:39:57.225 +0000 1220 1750 W ActivityManager: Slow operation: 90ms so far, now at startProcess: building log message --------- beginning of main 08-01 05:46:02.401 +0000 29231 29231 I AirWatch_VmwareSDKWHAccessController: disabled work hour restrictions on VMware SDK 08-01 05:46:02.401 +0000 29231 29231 I AirWatch_HubFeatures: Work hour restrictions feature toggled by user to UNAVAILABLE Dumpstate The bug report starts with the Dumpstate and shows detailed information on the hardware, software, network and system-related error logs. Right at the beginning of the log you can see when the Dumpstate was performed, which device model it is and which software build is installed. It also contains “netstat -nW”, for example, if you want to check the network connections at the time of the report. Dumpsys Information on all system and subcomponents is recorded in dumpsys. The dumpsys is a large part of the dump state. A few of the service dumps are very interesting for managed devices. DUMP OF SERVICE user This service dump shows all the details of the Android users. You can see whether a Work Profile (User10) or Personal Space (User11) has been set up. Users can have restrictions. For example, that no guest accounts (MultiUser) can be set up or that the Work Profile may not be removed. DUMP OF SERVICE account The service dump for accounts shows which accounts are set up for which user. This includes, for example, the automated Google account that is required for administration with Android Enterprise. DUMP OF SERVICE device_policy In the service dump for device_policy, you can see which applications are allowed to set and change policies. You can also check which policies have been set and which DPC is active. DUMP OF SERVICE package The dump for packages is very large! It has a Intent Resolution Table, lists which apps react to which MIME types or which permissions are used by which apps. Extensive data is also displayed for each app. These include, for example: appId, versionName, lastUpdateTime, declared / install permissions, install status / hidden app per user, etc. To find the relevant app quickly, you should search for “Package [packagename]” in the bug report. appId / UID / PID / TID There are various IDs that are associated with apps. The logcat in the bug report uses UID, PID and TID after the date. Unfortunately, only the PID and TID are displayed in the adb logcat. It can therefore be helpful to search for the UID and PIDs for an app if you want to trace an app error. Example: 01-10 10:58:57.522 1010269 16095 16095 I AirWatchVPN: PUM: Sending update request appId The Id for an installed app that can be found in the DUMP OF SERVICE package. Package [com.android.chrome] (db6f3db): appId=10197 UID The UID is a specific ID for an app per user. If an app is used by several users, the UID differs for each user. The UID is calculated like this: UID = User * 100000 + (appID % 100000) If Chrome is used in the personal space (User0), Work Profile (User10) and PrivateSpace (User11), there are the UIDs 10197, 1010197 and 1110197. Instead of calculating, you can also simply chain the UserId with the appId 10 “+” 10197 = 1010197 for the Work Profile PID (process ID) The DumpSys contains a mapping of all ProcessIDs under “PID mappings:”. PID mappings: PID #28694: ProcessRecord{c8faf8d 28694:com.android.chrome/u10a197} In this case, Chrome has the PID 28694 in the Work Profile at the time of the dump state. TID (ThreadID) If a process has only one thread, the TID is identical to the PID. If a process uses multiple threads, different TIDs will be used. Record the exact time of errors To avoid having to view a logcat entirely, you should make a note of exactly when an error occurred. If you don't want to make extra notes, you can also use the power status of the screen for this purpose The logcat records when the display is switched off or on. At 0 it is off, at 1 it is switched on. 01-10 10:30:45.863 1000 1678 1678 I screen_toggled: 1 01-10 10:33:48.081 1000 1678 1678 I screen_toggled: 0 01-10 10:38:41.860 1000 1678 1678 I screen_toggled: 1 01-10 10:43:32.290 1000 1678 1678 I screen_toggled: 0 Final Thoughts Depending on the cause of the error, troubleshooting can take different amounts of time and effort. An app that does not trust a TLS connection is easier to isolate than a bug in Android or a possibly faulty implementation by an OEM. I personally use Notepad++ to mark relevant package names, UIDs, PIDs and messages and was usually able to recognize the approximate cause. If anyone has more tricks in the area of bug reports or knows good tools for analyzing them, that would be very interesting. 😀
Unable to Add Work Profile on HONOR Magic V5 for Microsoft Intune Enrollment
Dear Android Enterprise Support Team, I am experiencing an issue while attempting to enroll my HONOR Magic V5 device into Microsoft Intune for device management. I just bought the device one week ago, but when I try to add a work profile, I receive the following error message: "Can't add work profile. A work profile can't be added to this HONOR Magic V5. If you have questions, contact your IT admin." This issue is preventing me from completing the enrollment process required by my organization. I have already consulted with my company’s global IT support team, and they confirmed that there is no alternative solution on our side. The only way to resolve this issue is for HONOR to make the HONOR Magic V5 compatible with the Microsoft Intune application and Android Enterprise work profile enrollment. Device Details: Model: HONOR Magic V5 OS Version: Magic OS 9.0.1 Android version: 15 Model: MBH-N49 Error Screenshot: attached as below Could you please advise if this device supports Android Enterprise work profiles or if there are any compatibility limitations? If there is a workaround or firmware update required, kindly provide guidance. Your prompt assistance would be greatly appreciated as this is impacting my ability to comply with company security policies.Tech Newbie interested in mobile cyber security, after multiple hacking events, seeking suggestions, tips, advice etc, to get involved.
Hello All, I am looking for advice, tips, suggestions, or helpful info, to begin a career/ journey into the world of Mobile Cyber Security and Tech. My interest was sparked after multiple hacking events that were very damaging to my life, my digital life, my work life, my relationships, my mental, physical, and emotional health, my data, information, and intellectual property of my business, and more. Now I am being pulled to learn how to protect myself first, and second so that I may be able to help others. I guess Ethical Hacking is the term. Any info helps. Thank you, Androidc3po[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, Jason
Share your deployment experiences with Android zero-touch enrollment
Hey everyone, In ‘5 Overlooked Benefits of Android Enterprise’, we touched on Android zero-touch enrollment, and it’s something many of you are actively using to streamline your device rollouts. For those in IT, Android zero-touch can be a powerful tool - see our handy guide to learn more. It’s about getting devices to your users ready to go, automatically enrolling in your EMM and pulling down all the right policies as soon as they connect. That means less hands-on time for your team and a smoother experience for end-users. We know real-world deployments always have their nuances, but it would be great to hear about your deployment experiences using zero-touch enrollment: Did you overcome any unexpected hurdles? What was the scale of your deployment - a few devices for new joiners, or hundreds for a company-wide refresh? If you could share one key tip or best practice for someone looking to nail their next zero-touch deployment, what would it be? We’re all here to learn from each other’s stories, and your insights are super valuable. I’m looking forward to reading your stories! Chat soon, Emilie
Request for Access to Android Enterprise Partner Portal Zero-touch Reseller Login
We are from Alphatech India and recently received a notification that our application to join the Carrier & Device Reseller Partner Program was declined. However, we would like to highlight that we are actively involved in large-scale deployments of Android-based mobile devices for enterprise customers across India. Access to the Android Enterprise Partner Portal, specifically the Zero-touch enrollment feature, is critical for us to streamline device provisioning and deliver a seamless experience to our clients. We request the community's guidance on how we can meet the eligibility requirements or explore any alternative process to gain access to the Zero-touch Reseller Portal. We are fully committed to meeting the necessary standards and are ready to provide any required documentation. Your support and direction on this matter would be greatly appreciated.Need Help with QR Enrollment for Multiple Devices in Educational Environment – Is External MDM Required?
Hi everyone, I'm managing a large number of Android tablets in an educational environment. I'm trying to enroll the devices using Android Enterprise with QR code enrollment, but I'm having trouble getting the QR method to appear. So far, only Zero-Touch shows as an option, but most of our devices were not purchased through Zero-Touch resellers, so we can't use that method. My main question is: Is it strictly necessary to use an external MDM (like Miradore, Intune, etc.) to generate the QR code, or is there a way to create and use it directly from the Google Admin console or natively through Android Enterprise? We want to deploy the tablets efficiently and avoid entering accounts manually. Ideally, each device would automatically enroll with our managed Google Play account by scanning a QR code after a factory reset. This is especially important in a school context, where we have many students and limited time for configuration. We are already registered in Google Workspace, and the tablets are in a dedicated organizational unit for students. The admin account is managed, and we are using the Android Enterprise platform linked to our domain. For reference, here are two YouTube videos showing the configuration steps I followed (which reflect our current setup): https://www.youtube.com/watch?v=jI-C_y1u8jE https://www.youtube.com/watch?v=h__pvfp559Q Any advice or clarification would be greatly appreciated. Especially if there’s a native way to enable QR enrollment without needing a full external MDM platform. Thanks in advance!
Issue with G Suite Apps Being Marked as Disabled in Play Store
Hi everyone, We are facing an issue where G Suite apps like Google Sheets, Google Drive, and Google Docs are installed on our managed devices, but when we check them in the Google Play Store, they appear as disabled. In some cases, the apps are randomly disabled, requiring manual re-enabling. We have verified: Google Device Policy settings Apps are approved and allowed in the managed Play Store Despite these checks, the issue persists across multiple devices with G Suite apps. Has anyone else experienced this issue? If so, do you know of any workarounds or if there is an ongoing Google-side issue causing this? For reference, I have attached a screenshot showing the issue. Looking forward to insights from the community! Thanks, Rupesh
