Android 15 - Cannot set default password app
We use Microsoft Intune to manage devices. For the devices which have upgraded to Android 15, the end users can no longer select Microsoft Authenticator as their default application for auto filling passwords. I cannot find any settings in Intune to allow it. All devices are fully managed corporate owned devices. The devices are all Google Pixel 8 or 8a devices. Is this a bug in 15 or am I missing something?[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[Day 1] Mobile Devices With a Sixth Sense: What Android Can Learn From Detection Dogs
Good afternoon everyone! Intro Alongside my passion for Android, which I’ve also made my profession, I spend a lot of my personal time working on scent detection training with dogs. Over the years I’ve trained my own dogs to search for items such as data carriers, phones, cannabis, and most recently one on cash. I wanted to participate in the festival because I had to skip the opportunity last year. But to contribute meaningfully, I wanted to create something that connects both worlds, Android and my other interests. This article is the result of that cross-pollination. The article is just a different perspective to discuss, a thought I had and a look in to what I think could be a good future. Android & detection / search dogs Enterprise mobility is still too often reduced to policies, profiles, and compliance checkboxes. A device shows compliant, an app is locked down, and the job seems done. But anyone who has worked with a well-trained detection dog knows that control is only half the story. The real value comes from analyzing behavior and context, and the ability to anticipate on what’s coming. Fun fact: Our nose, and a dogs nose, contain olfactory receptors, nerve cells that detect odor molecules, which is what we use to recognize a scent. An average human has around 2 to 6 million of those. A dog’s nose has around 250-300 million. They are capable of detecting so much more scents than we do. A detection dog doesn’t just smell an object. It smells the contents, the ingredients of what it’s made of and It detects deviations. It recognizes not only what is present, but also when a situation doesn’t match the pattern it expects. If something has disturbed the soil, it will recognize that. And as a handler you should be able to read to signals and act on it. If you want to go right, and the dog is showing that it recognizes a scent on the left, you should really go left and trust the signals your dog is sending you. As a dog handler I’m trusting my dog to make the right decisions, I just follow and guide the dog where needed. Lift him to higher grounds, or maybe mark areas of extra interest that I can see and I’ve been told to search. Its teamwork. Devices as Sensors Imagine a device that doesn’t only enforce policy but also understands what normal looks like in its environment. Not only checking whether something is allowed, but noticing when something is unexpected. A phone that has spent months connected only to Wi-Fi inside the warehouse but suddenly appears on 4G at two in the morning in another city, that may not be a direct policy violation, but it is something you and I would ask questions about. Any detection dog would pause, tilt its head, and quietly signal that something’s off. The ingredients to make devices smarter already exist. Smartphones capture motion, location, battery patterns, network behavior, app usage, and user interaction. Individually these are datapoints, but together they form a pattern, just like scent particles form a track for example. The interesting part is: the hardware has been ready for years. What we lack is interpretation. Fun fact: Did you know that when a dog is searching/sniffing, it can inhale and exhale up to 300 times per minute? If we would do this, we will start hyperventilating within seconds. I think Android could evolve in the same direction by learning baselines of enterprise-normal rather than relying solely on static policies. Once a baseline exists, devices can flag changes proactively, early before things escalate. An example Consider a warehouse worker scanning goods along the same aisle, during the same shift, using the same three apps every day. Android sees that, learns it, and identifies it as normal. But one Monday everything is different: roaming is active, a new route is taken, unfamiliar apps are running. Instead of asking only is this allowed?, the device could ask is this unusual?, should I report this?, is this risk or intentional deviation? As an IT admin, you could check those signals and take appropriate action. But maybe we want Android Enterprise to take their own actions up to a certain degree? This isn’t just security, it also improves stability, efficiency and less downtime. Combine all these and you might even have an employee who is actually happy with the work IT is doing. Instead of being the team who keeps blocking things, you become the IT admin that makes the devices just work when they need to. Closing note I am aware of different MDM’s providing such solutions such as WS1 and Knox Asset intelligence. But I think it could and should be so much better than that. It should be part of core Android OS, present for everyone, not just the one who can afford it but also the smaller companies with less budget. It shouldn’t be depending on a third party whether or not this works. Android Enterprise has matured. Policies are essential, but they’re not the finish line. The real opportunity lies in devices that understand normal, and detect subtle deviations before users even notice. Maybe it’s time our Android fleets developed a sense of intuition. Maybe it's time for Android fleets to develop their own sixth sense like a detection dog that quietly sits, nose raised, because it notices something no one else does yet.
[Day 3] Dedicated to Dedicated: Non-negotiables for EMM/MDM in Rugged Android Deployments
Disclaimer: The following article captures the opinion of Matt Dermody, Senior Director of Enterprise Mobility at Manhattan Associates. The stances contained within are a reflection of Manhattan's specific focus on line-of-business Android devices, built on years of being "Dedicated to Dedicated." Background Manhattan Associates is a B2B software company specifically focused on best-in-class, line-of-business enterprise deployments of enterprise software such as Warehouse Management (WMS), Transportation Management (TMS), and Point-of-Sale (POS). These software deployments command high expectations of uptime and availability, and that ultimately encompasses the complete solution, including the mobile computers that the software runs on. Manhattan is dedicated to ensuring that our end customers have the best possible experience, and that involves ensuring that the dedicated devices running our software are also properly maintained and supported. Google defines a "dedicated device" as a company-owned device that is fully managed and locked down for a specific work purpose, often using a single app or a small set of apps. These devices are restricted from personal use and are used for business functions like point-of-sale systems, inventory scanners, or digital signage. Or in other words, all of the device types that Manhattan sells, deploys, and supports alongside our software solutions. In that sense, I guess it can be said that we are… Dedicated to Dedicated. Managing rugged, line-of-business Android devices is not the same as managing BYOD phones and laptops. These are mission-critical endpoints running specialized apps in warehouses, stores, yards, and DCs—downtime costs money and local IT is increasingly rare. Your EMM/MDM must control versions, files, firmware, and field support with precision. Anything less adds risk and operational drag. Situation Imagine having to explain to a CIO that a business-critical mobile app has automatically upgraded to a new version that breaks functionality, and there is no easy rollback available. Here is a preview of how that might look. That situation is all too common but can be prevented with the right EMM/MDM strategies. The mere thought of that possible situation keeps the Manhattan team up at night. We have spent years developing strategies to add predictability and stability into enterprise device deployments to prevent bad situations from ever happening. Philosophies & Strategies Here is a preview of some of the core philosophies surrounding Manhattan’s tailored approach to managing mission-critical device deployments. Some of these might be controversial, but these are the strategies that work for us. 1. App Distribution and Version Discipline Rigorous version control of enterprise apps—stage, canary, bulk rollout, and rollback—is a must. Rugged ops cannot afford “surprise” app updates or version creep. If you can’t downgrade quickly, you don’t control your risk surface. An EMM/MDM should offer direct installation of private APKs on fully managed devices. Auto-upgrades to the “latest only” through Managed Google Play can lead to instability and version drift. Look for a console that can deploy specific app builds to specific groups on your schedule. If your tool can’t install an APK directly onto devices, it’s the wrong tool for rugged. Period. You must target different versions/configs by environment—Stage, QA, Prod—often per site group. That includes app versions, config files, etc. 2. File Management for App and Scanner Configuration LoB apps often externalize key settings via JSON and similar external config files. For example, Zebra DataWedge uses .db files placed in a specific auto-import directory to control mission-critical scanner settings. Your EMM must place, update, and replace these files on demand and at scale—ideally without anyone touching a device. Emergency changes (host cutover, DNS rename, scanner tweak) should be a file push away, not an onsite scramble. 3. Remote Control and Log Retrieval Treat full-fidelity Remote Control as table stakes. Support must see what the user sees, drive the screen, and pull logs and files in one session. Anything “view only” or bolt-on only erodes speed to resolution. Relying on reports from the floor or grainy pictures of an error taken from another device are not sufficient tactics for troubleshooting mission-critical device deployments. When issues hit, you don’t want an insurance policy like Remote Control that can be used to quickly diagnose and test solutions; you want a tool. An EMM admin without Remote Control is effectively blind with their hands tied behind their back. 4. OEM-level Controls (Zebra/Honeywell) There are numerous configuration settings that enterprise-grade OEMs extend beyond the baseline Android Enterprise configuration APIs. These OEMs are generally years ahead of what is available in base Android from a configurability standpoint and often introduce configuration settings that may otherwise never arrive to the base OS. These granular configuration layers ultimately are what set enterprise-class devices apart from consumer-grade technology. It is therefore imperative that an EMM managing these devices has the capability to manage OEM configuration extension features directly. For Zebra, this involves execution of their MX XML, DataWedge behavior, button mapping, radios, and other rugged-specific controls—through native profiles or integrated mechanisms. OEMConfig is useful, especially for parity across EMMs, but you will hit practical limits in closed networks and with Play-dependent timing/visibility. OEMConfig is a lowest-common-denominator functionality that was designed as a bridge to enable limited AMAPI-aligned EMMs to manage OEM-level settings with the limited tools at their disposal. Your EMM should support both OEMConfig (at a bare minimum) and offer the flexibility of direct MX/file workflows so you’re not boxed in by the limitations of distributing device settings through a complex web of Google Play server infrastructure. Your EMM should offer the ability to manage settings directly on the devices it manages, without the added layers and black boxes of complexity. 5. Firmware and Security Patching Over-the-Air (OTA) upgrades are great, but only when the EMM admin is in complete control. Auto-upgrades from the OEM pushed out over the air can bring production to a halt when critical business functions break. At a bare minimum, they can bring a network to a standstill as large upgrades are forced through the ISP connection into the building or site. An EMM should therefore offer integrations with the OEM-specific OTA and/or firmware upgrade protocols to put the controls in the admins' hands. 6. Lockdown and Kiosk Modes Rugged devices should boot into the work, not into Android. Enforce kiosk/lockdown, strict app allow-lists, settings restrictions, and consistent UX across every DC and store. The EMM should offer configurability over what is displayed on the lockdown, including personalization and customization to offer links to additional items such as launching apps, toolbars, or script executions. 7. Enrollment that Fits the Reality of Rugged Use Android Enterprise Device Owner (AEDO) with a barcode-driven process (e.g., Zebra StageNow). It’s fast, repeatable, and minimizes user taps and mis-taps on the floor. Wi-Fi credentials can be encrypted in the barcode rather than shared haphazardly and manually entered by end users into the Setup Wizard. More granular control over initial network connectivity is also afforded as compared with the limited options available through DPC extras if using the designated AEDO QR method. Avoid Zero Touch Enrollment (ZTE) for rugged Wi-Fi-only devices. ZTE is not "Zero Touch" as it realistically pushes many touches (and possible errors) to end users. There is overhead and maintenance to unenroll and re-enroll devices into the portal as they go in and out of repair. Enterprise-grade devices are often covered under repair contracts due to the nature of the environments they’re used in. This means they are going in and out of repair relatively frequently, and ZTE portal management ends up causing more bottlenecks than the steps it’s otherwise designed to free up. StageNow barcode flows are fewer steps and far more reliable for DCs and stores. 8. Closed Networks and Offline Constraints Many rugged sites have limited or no access to Google services. Your EMM must support managed app configuration and device policies in ways that don’t depend on real-time Managed Play orchestration. If your only path is Play-mediated, you’ll struggle with timing, visibility, and outcomes. Look for an EMM that offers “offline” or standalone Managed Configuration support by reading and exposing the configuration schema of an uploaded Enterprise app. 9. Health Analytics, Drift Detection, and Scripting Device health analytics (compliance, connectivity, install status) are critical for early detection and fleet stability. Pair that with a scripting engine and policy-driven rules (e.g., automatic relocation, auto-heal) to keep devices in line without manual human intervention. 10. What to Deprioritize (and Why) BYOD-centric EMMs that can’t directly install private APKs, can’t push files, and don’t include Remote Control as a first-class capability will drag deployments and support. Many EMMs specifically lack the granular APK/file control, versioning/rollback discipline, and integrated Remote Control required for rugged Android in DCs and stores; workarounds add fragility and cost without closing the gaps. Bonus – Identity and SSO Newer EMMs are offering advanced capabilities around Identity Management and SSO across business apps. As enterprise-grade devices become more multi-purpose, more mobile apps are being installed, each often with its own separate login requirements. Over time, there will be increasing needs to supply SSO workflows on-device across these business apps and to offer a clean pathway to script and automate the cleanup of a prior user’s session across all apps as they log off and make way for the next user to log in. If in the EMM selection process today, look for an EMM that offers these capabilities. Even if those features are not needed today, it is almost certainly the next set of features enterprises will look for and need to adopt. The Quick Scorecard If you can’t answer “yes” to these with your selected EMM/MDM, you’re taking unnecessary risk: Can your EMM install a specific APK build directly to AEDO devices? Can you canary a new version to one site, schedule a 2 a.m. cutover, and roll back instantly if needed? Can you push a JSON config change and a DataWedge .db to 500 devices in under 10 minutes—no manual touches? Can support remotely control the screen and pull logs/files from the same session? Can you execute Zebra MX XML, enforce kiosk/lockdown, and set scanner behavior centrally across models? Can you deploy LifeGuard/.ZIP OS updates by group, with maintenance windows and rollback? Can you enroll with StageNow barcodes (AEDO) instead of relying on ZTE flows designed for non-rugged scenarios? Can you operate cleanly in sites with limited/blocked Google services, including offline managed config workflows? Bottom Line A capable rugged EMM/MDM gives you deterministic control over versions, files, firmware, and front-line support—at fleet scale and on your schedule. Prioritize direct APK delivery, file distribution, OEM-level controls, Remote Control, AEDO barcode enrollment, and firmware orchestration. Deprioritize BYOD-first tools and any workflow that forces you through black box Play timing or pushes enrollment burden to associates on the floor. I’d love to hear what the comments have to say. Am I way off base? Do you fundamentally disagree? Or were you nodding along as you read through this. Let me know below! Oh and "AI", forgot to mention the buzzword. MattSporadic problems with Managed Google Play after enrollment
Hi! We had problems with a few devices after enrollment today. The Managed Play Store did not work properly. Restarting and waiting seems to help. Symptoms Empty collection in Managed Google Play Spaceship error, because supposedly no apps were made available Installation commands from the UEM did not work in some cases Apps assigned in UEM cannot be found in Play I was only able to reproduce the problem in one of 3 attempts. A few automatic app installations worked for me. However, it was not possible to search for the apps manually. Restarting the device and then waiting a while seems to help. However, a colleague had a strange error in Managed Google Play after a restart when he tried to install an app manually. "The item you want to buy could not be found." However, it is not a purchased app or an app with in-app purchases. Is anyone else currently having problems with Managed Google Play?
Recent Android change regarding Wifi configuration
Hi everyone, I just want to share the current situation we are leaving in my company and that could be interesting for other Android customers as well. With the Android security update released in May 2023, Google has changed some requirements to connect on a corporate Wifi. The "domain" value has now to be filled in the Wifi profile that is pushed on the device, otherwise the profile will not install on the device and the wifi connection will fail: https://developer.android.com/guide/topics/connectivity/wifi-suggest "The framework enforces security requirements on TLS-based Enterprise suggestions (EAP-TLS, EAP-TTLS, and EAP-PEAP); suggestions to such networks must set a Root CA certificate and a server domain name." This change was not communicated to our EMM vendor or to us and we started to have a lot of device that were impacted. Moreover our EMM vendor was not supporting this additional parameter in the console UI and we are in the way to upgrade our platform to finally have this support in the very last version released this week. I don't know if we could be warned in advance regarding such kind of change in the community because it has very huge impact for us and I guess for other customers. Luc
FYI - Chrome is dropping support for A8 and A9 in August 2025
138 will be the last version of Chrome that will support both A8 and A9 according to this recent announcement. https://support.google.com/chrome/thread/352616098/sunsetting-chrome-support-for-android-8-0-oreo-and-android-9-0-pie?hl=en There are very small populations of these devices left in the wild but I personally still support quite a number of them. The entire Atlas family from Zebra including the TC51, MC3300, and VC80x devices all max out on A8 with no higher upgrades available. This likely will lead to forced upgrades to those devices, especially given how many modern apps are hybrid web apps dependent on the WebView and/or Chrome (Chrome is the System WebView implementation on A8).Managing Google system updates with Android Enterprise
It's more important than ever to keep your fleet of devices secure and optimized for work. That’s where Google system updates come into play. Delivering updates from Google to the Android operating system, Google Play Store, and Google Play services, Google system updates make your Android devices more secure and reliable, whilst introducing new, useful features. But these need to be delivered in a timely way that works for your business and employees. So with that in mind, let’s cover the two main tools that can help you manage your Google system updates. System update policies Ideal for: Dedicated devices Pros: Keeps devices up-to-date, without relying on end-users to accept update prompts. Context: Between kiosk mode and digital signage, some devices are constantly running, and don’t necessarily have an assigned end-user to accept update and reboot prompts. In these cases, system update policies offer the perfect solution. They update the device either as soon as the update becomes available, or during a pre-set maintenance window to avoid active hours, so devices remain up-to-date and secure, without user input. There are also options to postpone updates, and freeze updates for a set period for particularly busy times of the year. Google Play system updates (also referred to as Mainline updates) are automatically downloaded as soon as they become available, but are not installed until the next device reboot - whether that’s prompted by user, admin or policy. Compliance policies Ideal for: Knowledge workers Pros: Gives users the flexibility to update on their own terms, whilst making sure devices don’t fall out of compliance. Context: For devices that are assigned to a user, pushing updates as soon as they become available may not always be practical. There’s nothing worse than joining an important client-call flustered and embarrassingly late, after an ill-timed system update. But, then again, companies want to make sure they’re making the most of the new features and security patches that come with each update. Compliance policies offer a balance between security and usability. They ensure that devices remain current against a pre-set standard, whilst giving workers the flexibility to apply updates at a time that suits their work schedule. The device will be tested according to certain signals, such as when the last update was made, or what version OS is being used, and prompt the user to update within a certain time-frame. Next steps These policies can be layered to make sure updates across your fleet are handled securely, in a way that works for your business. For more details on these tools, check out this Help Centre article. You can see what’s new to Google System update policies here. Make sure to also explore the documentation from your EMM provider for support on how these tools can be configured. Let’s get those system updates up-to-date! Have you got a system in place to manage updates? Does your business use one of these methods or a combination of the both? Let us know if and how you leverage these tools - we’d love to hear how they work for you![Product Update] Lock and locate Corporate devices with Lost Mode
Lock lost corporate devices and get real-time location updates to recover them. Android Enterprise admins, have you discovered Lost Mode? It’s a new management feature designed to safeguard your organisation's data and recover misplaced devices. No more frantic "phone-finding" missions or compromised sensitive information - Lost Mode empowers you to take control in challenging situations. Lost Mode empowers device management through: Remote lock down: Instantly lock lost or stolen devices. Gone are the days of helplessly hoping lost devices remain untouched; Lost Mode helps prevent unauthorised access beyond incoming and emergency calls, securing your data, and peace of mind. If the need arises, enrolled devices can also be remotely wiped. Real-time location tracking: Track the location of a lost device in real-time. Whether nestled under a colleague's desk or left in a taxi, Lost Mode can remotely pinpoint a device's whereabouts for hassle-free recovery. Lock screen message: Communicate company contact information directly on the lock screen. If found by a passerby, the pre-set company message will tell them where to return it. Or they’ll have the option to ‘Call owner’ on your chosen contact number with a press of a button, making good deeds a breeze. Audible locator: Turn your device into a beacon. When Lost Mode is activated, the device begins to ring on full volume, guiding you, or a helpful passerby, towards its hidden location. It’s a step up from breadcrumbs or wasting time aimlessly retracing your steps - follow the audible trail and reclaim your missing tech. How does it work? IT admins can easily put a device into Lost Mode from their EMM console. Once the missing device is found, and is back in the right hands, employees can simply exit lost mode with their device passcode and resume business as usual. Or, IT Admins can exit Lost Mode from their EMM console. Beyond immediate recovery, having this security measure in place enables quick action, minimising the risk of data breaches, improving employee peace of mind and eliminating wasted time searching for misplaced devices. Next steps Lost Mode is exclusive to EMMs that use Android Management API, and is currently available for both Work Profile on company-owned devices running Android 13 or later, and fully managed devices on Android 11 or later. To check if this feature has been made available in their console, please contact your EMM. For a step by step on how to enable Lost Mode on company-owned devices, check out this article in the Help Center. Otherwise it would be great to hear from you, have you or do you plan to implement Lost Mode into your device strategy? Which feature do you think will be most useful?
