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 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. Matt
Benefits of an EMM
What are the benefits of using a device management tool? Device management tools have had many different terms of the years… Mobile Device Management (MDM), Enterprise Mobility Management (EMM), Unified Endpoint Management (UEM). Whatever you prefer, they are undoubtedly the cornerstone of any successful IT project that involves hardware assets. Boiling down the core functionality of these tools, they allow IT admins the ability to use a single tool to view all of the hardware assets within their organisation, distribute applications and apply configurations based on their needs. Let’s start with the basics: Why do you need an EMM? As you have probably been able to discern from the different terms for device management tools, there’s quite a few benefits that are offered by introducing an EMM to your organisation. We can boil them down into three key buckets: Asset enablement and management I love a good spreadsheet as much as the next person, but monitoring what devices are within your organisation and have access to your corporate data simply cannot be done by a static tool. EMMs provide you a great platform to see all the assets within your organisation, who is using them and if they are compliant with your organisation's security policies. IT helpdesks are overwhelmed with inbound tickets and an EMM’s asset management capabilities can really help streamline this process. An EMM, integrated into your LDAP, can help shave minutes off every inbound request. Let’s run through a quick scenario that you may have faced: An end user can’t connect their phone to the WiFi in the office, they’ve followed your guidance and dropped an email into your IT team's support distribution list saying “I’ve come into the office and my phone can’t connect to the WiFi, it worked yesterday!”. Normally the first response will be to ask the user for details about their impacted device such as the device’s serial number, phone number and version of OS. But by simply copying their LDAP and pasting it into your EMM, you’re able to view all of the devices assigned to that user, as well as all of the details you’d usually have to ask for. Your EMM will likely present you with the initial steps to resolve the issue too. In this instance the user’s device is no longer compliant with the security policies, allowing you to respond with actionable information for your end user; update your device! Securing corporate assets and data Let’s start with the big one, is the Android platform secure? Our answer is, absolutely! The 2024 security paper should be able to answer any question you have if this is something you’d like to explore further. Now we’ve established the platform is secure, let’s get into why you need an EMM to secure your assets and data. Android Enterprise is designed to be flexible enough to meet your organisations security needs and EMM’s are the key to unlocking that functionality. In some instances simply enrolling devices into an EMM is enough thanks to Android Work Profile. But we can’t forget those working in regulated industries where data retention and handling is critical. My rule of thumb is, how can we keep devices secure without providing too much friction for end users? EMMs give you all the ingredients you need as an IT decision maker to create policies that meet your organisations requirements while also being considerate to end users. It goes without saying that all organisations should have a password policy applied, and for a lot of folks this may be sufficient. But depending on the type of work your users do there may be a requirement to add additional controls, such as preventing cross profile data sharing in Work Profile. As you go deeper into the realms of keeping your corporate data secure, data loss prevention becomes a real concern and you may need to further understand exactly what is happening on your devices. AI is a real inflection point for IT admins and a great point of reference for this topic. While AI is bringing game changing tools to users, the rapid rate of development and rollout is putting strain on security teams trying to evaluate the functionality to understand what data is being processed on device or in the cloud. Android Enterprise has already rolled out controls for IT admins to control what device features are available in Work Profile or on managed devices, but there are certain OEM native features, such as keyboards, where a global control may not be an option. This is where Android Enterprise’s flexibility really shines, allowing you to use various EMM controls to limit functionality through app configurations or, in this example, setting a different default keyboard. Keep an eye out for future discussions about how to determine if an AI process is being handled on device or in the cloud. Unlock hidden savings Downtime caused by device issues directly impacts workforce productivity. When a user's device fails, productivity grinds to a halt. Not only because they can’t perform their work, but they also need to wait for IT to resolve the issue. By enrolling your devices into an EMM you can transform existing IT support processes and enable the team to resolve more issues remotely. EMMs provide automation capabilities that create reports and alerts. This automation can proactively inform end-users if their devices are about to become non-compliant with corporate policies, reducing access issues and the subsequent support tickets. Beyond these automated alerts, EMM reporting tools also provide valuable insights for strategic decision-making. For example, reports from your EMM can be used to help you to make informed decisions about device refreshes, by reviewing historical data within your EMM you can reliably view the battery health of your devices and the average remaining storage on your devices. Upon reviewing the data you could see that perhaps you can get another year out of the existing hardware or if the amount of device storage needs increasing when it comes to selecting new devices. Now let’s focus on the process transformation enabled by these tools. By deeply integrating an EMM into your support flow you can drastically reduce the time to resolution of most device related issues. I’ve frequently seen IT teams that haven’t done this require end users to “swing by their desk” with an issue, while this comes with the best intentions it is extremely disruptive to end user productivity. Let’s imagine a user has an issue with one of their applications, if the user was in person it is likely that a member of IT staff will try all the basics such as deleting device cache, reinstalling the application and eventually updating the devices firmware. In contrast, with devices enrolled in an EMM, the IT team can quickly identify the user via LDAP within the EMM console. The console will provide immediate insights into the device's compliance status, potentially revealing that the user’s device is non-compliant with security policies and providing a clear path to resolution. Why do your users need you to have an EMM? As an IT admin the goal when rolling out technology to an organisation should be to remove friction and empower our users, an EMM is a fantastic tool to enable this. Seamless access The utility of an EMM starts from the moment a user enrolls their device. If you’ve connected your EMM to your identity provider, the user can use the same login credentials they use on their other devices, coupling this with an SSO provider will allow them to seamlessly sign in to their applications. Immediately online “What's the WiFi password?” While we can’t solve this for you at home, an EMM at least prevents this question from being asked in the workplace. Creating a WiFi policy allows you to push down your WiFi credentials to all devices enrolled into your EMM. Quite a few organisations rely on VPN connectivity for their users to connect to corporate networks, this is also no problem for an EMM. Application distribution Smartphones have a vast amount of functionality out of the box, but I’m yet to come across a phone that ships with every app you need! While there is an element of enjoyment to scrolling through the Play Store and finding the apps you need, it can be very cumbersome when you have to do more than a handful. By using an EMM integrated managed Google Play you can approve applications for use within your organisation, creating a curated list of apps that your users can download. Additionally, you can also decide which applications are pushed to your users. Meaning those apps will automatically install on your users device once they have completed enrollment into your EMM. I would generally recommend limiting this to applications that are critical to your end users, such as email and calendar, but you can always change this based on feedback from your users. How do you choose an EMM? We’ve covered just a handful of the benefits of an EMM here, but there is so much more! This space has been evolving at a rapid pace ever since its inception, every day EMM’s receive dozens of feature requests and each has their own interpretation of how best to present information to IT admins. Go in with a plan Before you engage an EMM for evaluation, build out a plan for what you are trying to achieve with your devices. This will not only help you get a better grasp of the discussion but also ensure you have a clear success criteria for your proof of concept. To help you with your plan, here’s a few questions you’re likely to be asked: How many devices are you looking to enroll? Are you buying the devices for your users (corporately owned) or will they use their own devices (BYOD)? What do your users do with their devices? What apps do your users need? Who is your identity provider? What security policies do you need to comply with? When do you plan on starting this project? How to find an EMM You can’t go wrong with one of our Android Enterprise Recommended EMM partners! Thanks for reading! Are there any other key features that you utilise within your EMM that we haven’t covered here? Let us know!
[EMM] My Android EMM Registered account is forced to re-register Android Enterprise.
Hello all, I have my business account registered with Android EMM Registration for about 5 years. About a month ago, there was a problem with API connection with an error message 'UNAUTHENTICATED' reason 'CREDENTIALS_MISSING' which impact on device enrollment and app push service. I have no luck finding ways to fix it and I cannot open any support case with my free account. I decided to reconfigure Android EMM Registration with the same account. Google directed me to newly register enterprise account ended up with same account but different 'Client ID' and 'Google Service Account Email Address'. All my apps in private store and previous managed app are missing. Is there any way to bind my email account back to Google Client ID? so I don't have to separate manage apps and devices on my EMM system. Note When I login to Play Work, I still can see my previous 'Client ID' profile. However, on EMM system, it shows my new client profile. Regards, BKP
Fido2 key and their issues using them on Android
First, do Android support using Fido2 keys on Android? Yes, it does support both using bluetooth, NFC and USB authentication. For reference: https://developers.google.com/identity/fido/android/native-apps But does it mean that it is straight forward to use it in a enterprise environment without hiccups? No, the support lacks many features that both Windows and iOS has supported for long time. If I buy a modern Fido2 with OTP support, will it work straight out of the box for using the USB? No, you need to disable the OTP support first. Here is how you can do that from yubikey manager, this works for Yubikey. Other vendors might have something similar. But for Fido2 keys without OTP support, it should work out of the box for USB-C, like Google titan. Why this happens, dont know. Can we use NFC for Entra ID authentication like we can on Windows and iOS? No. Android does not currently support CTAP2 for NFC, only for USB-C input. CTAP1 (FIDO U2F) supports certificate based authentication, but CTAP supports user verification with PIN and biometrics. Entra ID requires UV (user verification) before accepting login. As far as I know, there is also support for bluetooth. But I dont have any fido2 keys that support bluetooth yet. So why does this matter? With Android you can have shared devices with secure login for multiple users with a single log in for all supported apps, auto log off and many other possibilities. https://learn.microsoft.com/en-us/entra/identity-platform/msal-shared-devices Other sources/discussions: https://www.reddit.com/r/yubikey/comments/1oncuh2/whats_the_point_of_nfc_on_android/ https://www.reddit.com/r/yubikey/comments/13tlzoc/fido2_inconsistent_across_windowsandroid/ https://fidoalliance.org/specifications/
(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!
Google Advertising- ID ( AD-ID)
Hi i´m looking for an option to disable/clear the Advertising-ID (AD-ID) on a fully managed Device, i found the KB https://support.google.com/googleplay/android-developer/answer/6048248?hl=en Is there any option to remove or clear the AD-ID from EMM/MDM side without a User action? and is there any more detail information how AD-ID is working on an managed Device? Appreciate your feedback Bjoern
