EOL Status of OpenCensus Jars and Request for Migration
During a recent review, we noticed that some of the Android Enterprise dependencies we use — specifically opencensus-api and opencensus-contrib-http-util — have not been updated for several years. --> Last release: 0.31.1 (April 29, 2022) These libraries are currently required as dependencies for google-http-client.jar, which we use to initialize HTTP clients for API calls. If we exclude the OpenCensus jars, the application fails at runtime with missing class errors. Therefore, these jars are currently mandatory for successful execution. However, from a security perspective, our central security team does not allow bundling outdated or unsupported dependencies. We would appreciate your guidance on the following points: Are there any plans to update or refactor google-http-client.jar to remove or upgrade its dependency on the legacy OpenCensus libraries? Is there an alternative approach or supported path to use OpenTelemetry (or any other supported telemetry library) in place of OpenCensus for tracing and metrics? We already raised in following portals and no update received, so posting it here AE Partner Escalations Git hub discussions Expert Forum Any roadmap updates or migration guidance would be extremely helpful.Google Play update: new layer of security coming in 2026
Hello everyone, To enhance security on Android devices, Google has announced that developers of Android applications, including those distributed outside of the Google Play Store, will be required to complete developer verification in order for their apps to be installed on Android devices. This new policy is designed to combat the spread of malware and financial fraud by increasing developer accountability. Rollout starts in September 2026 for Brazil, Indonesia, Singapore, and Thailand. This requirement will be expanded globally in 2027 and beyond. We understand that enterprise organizations often use off-Play methods of distribution methods for private applications. As such: Applications installed on fully managed devices (DO) or within Work Profiles (BYOD and COPE) can continue to be installed, without developer verification, until September 2027. After this point, developer verification will be required for the app to be installed. Applications installed by EMM Device Policy Controllers (DPCs) will be exempt from requiring developer verification indefinitely. (For example, apps installed via Workspace ONE Intelligent Hub, Intune Company Portal, SOTI MobiControl, etc.) Private applications installed with Managed Google Play will be exempt from developer verification indefinitely. We would welcome your feedback on other application distribution methods used by your company and how this recent announcement will impact you. The Android Enterprise Team *Article updated 4 Sept 2025, by CM - minor text removal for clarityEnhanced Factory Reset Protection in Android 15
Factory Reset Protection: A Shield for Everyone Smartphones and tablets have become integral to our work and personal lives, however, they can also be easily lost, and on occasion, stolen by opportunistic thieves. Many times these bad actors will simply wipe the device to remove any personal and business data, with the intent of selling or using the device themselves. That's where Factory Reset Protection (FRP) steps in as a crucial line of defense. FRP is an Android security feature designed to prevent the reuse of a lost or stolen Android device. It requires your Google account or lockscreen credentials after a factory reset, ensuring that only the rightful owner can access and use the device once it has been wiped. Enhanced Factory Reset Protection Building on its initial purpose, FRP has evolved significantly with the release of Android 15. In the past, tech-savvy thieves and users found ways to bypass FRP, but Android 15 closes those loopholes with powerful new protections. These enhancements were added to combat unauthorized access and make stolen devices much less appealing to thieves, whether they're targeting personal or company-owned devices. Prior to Android 15, the Setup Wizard was responsible for determining whether FRP should be activated, and for enforcing it, including determining whether you have authenticated with the correct credentials to get out of FRP mode and proceed with setup normally. But the Setup Wizard was designed to be a user-friendly tool to walk through setting up a device, not a security enforcement barrier. In Android 15, FRP enforcement has been moved deep into the system, where it’s much harder to overcome. Benefits You Can Count On These enhancements translate into real-world benefits for everyone: Individuals: Deters Theft: FRP makes stolen devices far less valuable, as thieves can't bypass the Google account login or lock screen credential check. This significantly reduces the incentive for theft. Peace of Mind: Knowing that your Android device has this robust security feature gives you peace of mind. You can rest assured that if your device falls into the wrong hands, it cannot be used for anything. Enterprise and Managed Devices: Enhanced Device Security: Factory Reset Protection makes it much harder to reuse or sell stolen devices, which discourages thieves from stealing them in the first place. Simplified Device Management: FRP integrates seamlessly with enterprise mobility management (EMM) solutions, allowing IT administrators to enforce FRP policies and ensure devices are protected. With Android 15, FRP has evolved into a powerful deterrent against device theft by making stolen devices unusable.
Intermittent QR Code Provisioning Failures with Identical Source Code
I am experiencing inconsistent behavior with QR code provisioning for Android Enterprise and am seeking guidance from the community. The Issue: QR code provisioning works intermittently, but the failure pattern is inconsistent. A provisioning QR code generated from a specific APK build will work reliably. However, subsequent builds of the exact same source code from the same Android Studio project will sometimes fail. The device displays a generic "Contact your IT admin" error. What I've Verified: The APK is properly signed and the checksum in the QR code is correct. The server delivers the APK with the correct application/vnd.android.package-archive MIME type. The DeviceAdminReceiver is correctly declared in the manifest and the associated XML resource exists. The package name and component name in the QR code are 100% accurate. Comparing a "working" APK and a "failing" APK in APK Analyzer shows no differences in the core components (package name, receivers, resources). Question: Has anyone else encountered this? Are there known issues with Android's provisioning service being sensitive to certain aspects of the APK build output that are not related to the core functionality or signature? Any insight into how to achieve consistent, reproducible builds for provisioning would be greatly appreciated.The Secure Element podcast - Episode #4: Device Trust
Hey Friends, Ready for the inside scoop on Device Trust from Android Enterprise? This episode of The Secure Element dives into the buzz from the recent Oktane event! I sat down with Karthig Balendran (Product Manager at Okta) and Al Chapelle (Senior Product Manager at Android Enterprise) to discuss our highlights from the event, as well as the practical implications of Device Trust from Android Enterprise on your organisation’s security posture. Join us as we dive into: Fine-grained access: A deep dive into the Device Trust from Android Enterprise framework and how it uses real-time, device-level security signals for precise access control. Partnership in action: How Android Enterprise and Okta are teaming up to bring this new security solution to customers. Security for BYOD: how Device Trust from Android Enterprise unlocks enterprise-grade security on unmanaged, employee-owned android devices. Customer reaction: Hear how the demo was received by customers at Oktane. Listen to the episode here: If you haven’t already, check out episode 1, episode 2 and episode 3 for more conversations with industry experts across all things security. As always let us know any questions or comments you have below, and we’ll be sure to follow up. Stay secure, Burr
Why openNetworkConfiguration not working in enrolled device?
I have enrolled a device and want to use managed wifi on that device. I have used following configuration- "openNetworkConfiguration": { "Type": "UnencryptedConfiguration", "NetworkConfigurations": [ { "GUID": "inovex_wifi", "Name": "INovex-Dev", "Type": "WiFi", "WiFi": { "SSID": "INovex-Dev", "Security": "WPA-EAP", "EAP": { "Outer": "EAP-TLS", "Identity": "faruk", "DomainSuffixMatch": ["dms.mobi-manager.com"], "ServerCARefs": ["ca_inovex"], "ClientCertType": "Ref", "ClientCertRef": "client_inovex" } } } ], "Certificates": [ { "GUID": "ca_inovex", "Type": "Server", "X509": "ca_base64" }, { "GUID": "client_inovex", "Type": "Client", "PKCS12": "client_base64" } ] } My expection is This network automatically save in wifi list As I set client and server certificate the device should connect automatically For information I have used freeradius server for authentication.Android 16 STIG is now live!
Hey friends, We are pleased to announce the release of Google’s Security Technical Implementation Guide (STIG) for Android 16. Developed in partnership with the Defense Information Systems Agency (DISA), this guide provides a robust, expert-defined security baseline for organizations that require the highest level of security. It is an essential resource for government, defense, and security-conscious customers like FSI and Healthcare, who handle sensitive data and operate in compliance-driven environments. What is a STIG? A STIG is a detailed security checklist designed to “harden” an operating system. In short, it’s a technical manual that provides prescriptive, step-by-step guidance on how to adjust default settings, disable unnecessary functions, and configure a system to protect against common vulnerabilities. By following a STIG, you proactively close the doors that cyber attackers often use to exploit systems. Who can benefit from the STIG? While STIG compliance is mandatory for DoD (Department of Defense) and federal agencies, its guidance represents the gold standard for security that any organisation can use to improve its security posture. Specifically, the Android 16 STIG provides official configurations for devices deployed in Corporate-owned, business-only (COBO), and Corporate-Owned, Personally-Enabled (COPE) management modes. The key value for your business Adopting the Android 16 STIG goes beyond meeting a mandate, enabling several key business benefits. Achieve the highest security posture: The guide closes configuration weaknesses and minimizes your system’s attack surface, dramatically improving your defence against threats and enhancing system resilience. Ensure mandatory compliance: For federal and DoD-connected systems, STIG compliance is a non-negotiable step to meet the Risk Management Frameworks (RMF) and gain Authority to Operate (ATO). Unlock a standardized and efficient management framework: It provides a single, expert-defined security baseline across all your devices, which simplifies system auditing, prioritizes critical fixes (using the CAT I, II, III severity levels) and streamlines auditing and reporting. Ready to strengthen your security? Get everything your team needs to harden your Android devices, meet compliance mandates, and build a more resilient mobile fleet directly from the DISA repository. ➡️ Download the Google Android 16 STIG here For those interested in federal device certification, our latest episode of The Secure Element delves into the approval process for Android devices in compliance-focused sectors.The Secure Element podcast - Episode #3
Hey Friends, Episode 3 of The Secure Element is here! This month, I spoke with Brian Wood who runs the Android Certifications Programs to demystify what it takes to get a device approved for the federal government, a process that also benefits other security-focused industries like finance and healthcare. Join us as we dive into: The exact process for federal government device certification. The roles of NIST (National Institute of Standards and Technology) and NIAP (National Information Assurance Partnership) in setting security standards. Debunking myths about Android encryption, including its standing against iOS. Listen to the episode here: Thanks for tuning in! We’d love to hear your thoughts or any further questions in the comments below and we’ll be sure to follow them up. New to the series? Listen to Episode 1 and Episode 2 to hear more insights from industry leaders. Stay secure, Burr
DPC Extras issues
Hello, I hope you're doing well. I'm reaching out for assistance on an issue I'm experiencing with DPC extras on ZTE devices. Is there a method to implement DPC extras without using a QR code? It appears that even when configuring ZTE with DPC extras, some functionalities do not activate. Additionally, several design elements seem less than optimal. For instance, if you do not use a QR code before selecting the language—which, ideally, should be sourced from the DPC—there's an option presented to transfer data from another device. This option seems inappropriate for a company-owned device. Could this be improved? The next screen prompts a WiFi connection. Using a QR code skips this step, but users still need to manually confirm the WiFi connection. Could this be streamlined? Is it possible to enroll a device as an admin, reset it, and have the DPC extras from the QR code persist on the device until it connects to WiFi and verifies its management status? It seems everyone is adding devices to ZTE for security reasons, particularly for stolen devices, yet the reliance on QR codes adds unnecessary complexity. Could this process be made more user-friendly?
