[Product Update] Zero-touch enrollment enhancement: Multi-Identifier Registration
*[Updated 17th, September 2024 -enhancements are now live] Hello everyone, We're excited to let you know about some upcoming enhancements to the Zero-touch enrollment process that will give resellers greater flexibility over device registration. Key Improvement: Multi-Identifier Registration Soon, your reseller will be able to register a device using multiple identifiers: Serial number, manufacturer, and model combination Up to two hardware IDs of the same type (either MEID or IMEI) This change will bring several benefits: Improved provisioning reliability by reducing the risk of registration failures due to identifier mismatches. Enhanced inventory management with the ability to track devices using multiple identifiers. Important Note: These changes will be reflected on the zero-touch customer API. Timeline and Next Steps These change are now live. Please contact your reseller to discuss this further. We hope these improvements will greatly enhance your experience with Zero-touch enrollment. As always, we'd love to hear your feedback. If you have any questions about this announcement please comment below. Thank you.Android zero-touch customer portal
Learn more about the changes to the new zero-touch customer portal The new zero-touch customer portal has been designed to make it easier for you to manage your account. Here are some of the key changes: New look and feel: The portal has been redesigned with a modern look and feel, making it easier to navigate and find the information you need. Improved navigation: The navigation menu has been simplified and reorganized, making it easier to find the pages you're looking for. Updated Terms of service: Updated the zero-touch customer terms of service and customers will be prompted to accept the terms of service upon next login to the zero-touch customer portal. The terms of service need to be accepted once by an admin or owner of the customer account. If you own multiple accounts, you might need to accept the terms of service for each one. Note: when attempting to access the zero-touch customer API. Any existing solutions leveraging the zero-touch customer APIs to access an account that has not yet accepted the new terms of service will receive a TosError response. Users will need to accept the terms of service by signing in to the zero-touch enrolment portal. New features/changes: The portal now includes a number of new features, such as: Improved search: search for specific device(s) by the fields below, without specifying which identifier(ie. IMEI, MEID, serial number). Additional fields on device CSV download: You can download a CSV of existing devices assigned to your organization, which contain all data seen on the device management page with additional field(ie. Reseller name and reseller ID). Additionally, unified the formats so the customer can download a CSV, make changes to the profiles, and upload it. Undelete account: You can no longer undelete the account once deleted, alternatively you can reach out to your reseller who can then reach out to us to recover your account with valid reason. To access the new customer portal, simply go to link. You will need to log in with your existing username and password To help you navigate the changes, please refer to the customer portal guide. We value your feedback, please use the feedback button as shown in the attached GIF to share your insights: If you have any questions about the new customer portal, please create a new community conversation in the General Discussion board. Thank you.[PRODUCT UPDATE] Zero-touch enhancement: New admin controls
Hello everyone, We're thrilled to announce significant enhancements to the zero-touch customer portal, designed to provide greater control over customer data. The portal's role-based access control has been updated to include three new user roles, ‘Manager’, ‘Assigner’, ‘Viewer’, for greater control of the data and capabilities each portal user has access to. Read this Help Center guide to learn about these new roles and how to add users to these new roles. Migration Timeline: This is now available. We know many of you are excited to have this new capability, thank you to those of you who provided feedback and input. It would be fantastic to hear your thoughts, are you planning on using these new roles in your organisation or any additional questions, below. Thank so much. *Timeline updated 24 June, 2025
[PRODUCT UPDATE] Zero-touch enhancement: Audit logs
Hey everyone, We're pleased to announce a significant enhancement to the zero-touch customer portal, designed to provide greater transparency over your data. Comprehensive audit logs, offering a detailed and accessible record of all actions affecting your customer data will soon be available in the customer portal. Key Improvements: Comprehensive Logging: Captures actions taken from all possible sources eg: zero-touch customer and reseller portal, customer and reseller API. Tracks all data related to a zero-touch customer, including: Users Devices Resellers Configurations Terms of Service CSV Files Zero-touch customer accounts Easy Access and Analysis: Access audit logs through a user-friendly interface within the portal. Download logs in CSV format for further analysis and reporting. Benefits: Accessibility and Analysis: Ensures easy access and analysis of logs. Enhanced Security: Provides a detailed record of all activities impacting customer data, enabling better monitoring. Streamlined Troubleshooting: Quickly identify and resolve data-related issues with detailed activity logs. Increased Transparency: Offers greater visibility into how your customer data is being accessed and managed. Important Note: The audit logs are only available via the zero-touch customer portal. There is no change to the zero-touch reseller portal, Reseller API, and Customer API. Migration Timeline: This feature will be enabled during the next few weeks. Only logs after March 2025 are available in the zero-touch customer portal. If you require older audit logs, please contact your reseller who can raise a support ticket. We hope you find this enhancement useful. To learn more, please refer to this Help Center guide. It would be fantastic to hear your feedback or any questions below. Thanks so much.[Product Update] Dynamic duo: improved dual-SIM support in Android zero-touch
Note: this article has been updated on 03.04.2024 to reflect improvements to the process of provisioning dual-SIM devices via zero-touch. Please see the below steps for best practice. As individual tools, both zero-touch enrollment and dual-SIM devices offer a wealth of business benefits. But until recently, the two IMEI numbers - one for each SIM card - in a dual-SIM device meant integrating dual-SIM with zero-touch was unreliable and dependent on SIM configuration. The good news: we’ve enhanced dual-SIM support in zero-touch, improving the reliability of dual-SIM enrollment, and simplifying management. What does this mean? This improved integration addresses the known issues some users have previously experienced when provisioning dual-SIM devices with zero-touch. It means dual-SIM devices don’t need to be registered as two separate devices to be reliably managed. It also minimises the risk of devices being missed during provisioning and getting stuck in a reset loop, or randomly undergoing factory reset. There is no action required to activate this fix, and you’ll only be visibly impacted if you’ve experienced the issues above. Otherwise, we’d recommend you continue to follow the steps below as best practice. Here's how it works: Lead with the lowest IMEI: For zero-touch to recognise and configure dual-SIM devices, the device initially needs to be registered with the numerically lowest IMEI. For example, if the two IMEI numbers are 000000000000001 and 000000000000002, you would register the first. Zero-touch to go: Upon boot up zero-touch will detect the device and provision it, applying your preconfigured settings and apps. Cue smooth sailing. Tips for a smooth two-step Be aware: If your device is preinstalled with a version of Google Play Services prior to 24.07.12, after setup zero-touch will detect the device, register its serial number, and prompt a factory reset. The next time you set up your device, it will be provisioned through zero-touch. Communicate with your reseller: Make sure they understand the importance of registering with the lowest IMEI for dual-SIM devices. Test, test, test: When integrating dual-SIM devices with zero-touch, begin with a test batch to identify and troubleshoot any hiccups. You may also wish to check this documentation for any known issues. Documentation is key: Clearly document the specific steps for dual-SIM zero-touch deployment so users know what to expect when setting up. For more details including prerequisites, configurations and a getting started guide, check out this zero-touch enrollment for IT admins article. [To add, to find out how to view the second IMEI number in the Zero-touch portal, take a look here.] Now, it's your turn to share your thoughts. Do you currently use a dual-SIM device? If so, how do you use it? Was it provisioned through zero-touch? *Updated 23/4/25 - to add a link to the Help Center article on how to find the second IMEI number12 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!
Installed device policy used for hacking.
This device policy was installed on my phone through firebase from Google. I I have reported this to Google in regards to the hacking and the device control I cannot uninstall it and I show a shell manifest on my phone to be using the developer platform to redirect everything through Androids system. So either someone has hacked into the Android platform and as redirected everything or this is an open-ended warrant for 5 years now for an invasion of my privacy. Either way the Google is liable by either not protecting my privacy or by complying with such an order for 5 years and never asking why. You can look at my Facebook page and see exactly why this invasion of privacy has been ongoing. Jim Mininno or Vincent Mininno. I plead with someone to help me get this results as me and my children has been made the victims of the department of defense and Google.
(COPE) Hide app in work profile
Hello, I have a small case I'd like to submit to the community for help please. A customer use Mobile Iron, and use Zero Touch to enroll our Android 14 products. In their DPC extras, they enabled the system apps and need to keep that way: "android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED":true, "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{ "workProfileEnabled": true, "quickStart":"true" } Now after the device is enrolled, the Work profile is filled with bunch of apps including unwanted ones like Netflix, Adobe, YT kids, ... From Mobile Iron, they want to hide/disable some apps, using "setApplicationHidden" but it doesn't work. At OEM side, we tested this API with the Test DPC and it works properly. My thinking was that as we are in COPE, and the apps that the customer wants to remove are from the Personal space, then this is not working as the MDM cannot interact with Personal space content. Does this make sense? Are there a way to hide the unwanted apps from the Work profile, despite having "leave all system apps" enabled from the ZT DPC extras? Anyone has any suggestions please? Thanks!
No information about uploaded devices
There is no information about uploaded devices by the reseller. We purchased devices in couple parts. It would be great if we could see when, how many and from which reseller the devices were added to zero-touch. Also it seems that there are few devices missing from the list of devices. Maybe it was intentionally done by one of the admins but it would be great if there was a log of what was done by the admins.
