Security
100 TopicsEnable ADB debugging is grayed out - This setting is managed by your administrator
This issue was documented in 2021 but with no solution. My Chromebook is managed by my company and I am the manager. But Google tries to find the managed option to unlock for this to work in the administration interface for more than 15 days without success. By the way there are thousands of options in the admin interface it could be a clever feature to number them. If you are in front of the same issue please add your comments to this post. I hope that Google support will succeed to solve the issue soon because I developed my first app for Android on my Chromebook with Android Studio and I was able to download it to my phone before these 15 days.108Views1like8CommentsEnabled FRP and now I'm stuck
We're building an Emm solution so while testing I enabled FRP and thought of giving it a shot. So, after factory resetting all i can see is a google window asking me to verify with the account that was previously in the device. What I cannot understand is there was no account signed in except the one google created ( the managed account with the briefcase thingy ). I'd like to understand how can i recover it now? i do have some of the device details on enterprise.devices.get endpoint. Any help would be much appreciated! Rino.Solved158Views0likes8Comments[Product Update] RCS Archival is now available on managed Android devices
Rich Communication Services (RCS) is a significant upgrade that benefits businesses with enhanced security through end-to-end encryption and boosted employee productivity with features like read receipts, typing indicators, high-resolution file sharing without size limits, and seamless group chat management. However, RCS encryption can present a challenge for regulatory compliance. To ensure companies can fully utilise these security and productivity benefits of Google Messages while meeting crucial record-keeping requirements, we are rolling out Android RCS Archival. Feature benefits This new capability streamlines message auditing by integrating directly with Google Messages, enabling third-party archival apps to capture all communications so that auditing is: Comprehensive: The archival app is notified on all message events, including when a message is sent, received, edited or deleted. This provides a complete audit trail that is also backward compatible with SMS and MMS. Reliable: Unlike previous methods, this is a built-in, Android-supported and maintained archival mechanism. Controlled: IT admins maintain full control over deployment and can easily enable or disable this feature, with employees receiving clear notification when archival is active. Scope and implementation Android RCS Archival is available on fully managed Android devices using Google Messages as the default messaging application. For a full breakdown of the benefits of RCS archival, check out our keyword blog. For implementation details and configuring the policy, consult our Help Center article.335Views1like4CommentsEOL 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.90Views0likes4CommentsDo certifications matter when researching new devices?
Hey everyone, Episode 3 of The Secure Element went live last month! Bigdogburr (our go-to security expert) sat down with Brian Wood from Google’s Device Security and Privacy team to unpack how devices get approved for use in the US federal government. Spoiler: it’s not simple! From government-approved labs running tests, to annual re-certifications, to the role of NIAP (National Information Assurance Partnership) — there’s a lot going on behind the scenes to make sure devices are truly secure and trustworthy. When you’re looking at new devices, do you pay attention to security certifications or accreditations? If so, what certifications are you most interested in your region? Or do you focus on something else entirely? Let me know your thoughts below — I’d love to hear how you approach this! Chat soon, Emilie29Views2likes0CommentsIntermittent 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.55Views0likes1CommentGoogle 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 clarity882Views6likes5CommentsEnhanced 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.9.8KViews6likes15CommentsThe 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, Burr169Views3likes0CommentsWhy 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.41Views0likes3Comments