Recent discussions
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.
SCEP Certificate Fails with Multiple Root CAs on COPE/COBO (Works on BYOD)
Hi everyone, We're running into a certificate issue with our Android Enterprise deployment and hoping someone here has encountered something similar or can point us in the right direction. We're using Microsoft Intune as our MDM solution with COPE and COBO enrolled devices. This affects all Android devices regardless of manufacturer, including Google Pixel devices running Android 16 with the latest security patch. The devices use SCEP certificates for Wi-Fi authentication. In early September, we rolled out new Root CAs via Intune. These new Root CAs are used for creating SCEP profiles for Wi-Fi authentication. The devices now have both the old, still valid Root CA and the new Root CA installed. The problem occurs when a device tries to obtain a new SCEP certificate issued by the new Root CA. In this case, the Android device attempts to verify the certificate chain using the old Root CA, which fails because the certificate was issued by the new Root CA. As soon as the old Root CA is removed from the device via MDM, the certificate verification works as expected. Interestingly, the entire process works without any problems on Android devices with personal enrollment (BYOD). We've tested creating a new SCEP profile, but unfortunately that didn't help. Only removing the old Root CA solved the problem. The issue now also occurs with BYOD devices as well. Has anyone dealt with a similar situation during a Root CA migration on Android Enterprise devices? We're trying to understand why COPE and COBO devices behave differently than BYOD devices in this scenario, and whether there's a configuration we're missing that would allow both Root CAs to coexist properly during our transition period. Thanks in advance for any help you can provide.
Google keyboard not appearing automatically
Have a bit of an emergency where after the latest Gboard update, when users tap an input field, instead of Gboard just showing up as normal, a menu bubble is appearing instead where they have to tap it and select the "show on screen keyboard" option. I haven't been able to locate Google's release notes for Gboard to see if there was something that changed. Any ideas would be greatly appreciated!
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.
Can't configure notifications on my work profile
I hope someone here can help me, since I've been stuck in this issue for over a month now. I can not configure notifications on my work profile. I am the admin so should be able to allow this for users. I'll share some screenshots to illustrate the issue. First, the disabled notification: Then, the advice of gemini: The Solution: Change the Admin Policy You must log in to your Google Admin Console and change the setting that is blocking this. On your computer, log in to your Google Admin Console at admin.google.com. In the left-hand menu, navigate to: Devices $\rightarrow$ Mobile & endpoints $\rightarrow$ Settings Click on Android. This page lists all your Android policies. You are looking for the setting that controls app permissions. It is most likely in one of these two sections: Primary Target: Apps and data sharing Look for a setting like App permissions or App settings. The current setting is likely "Block user from modifying" or "Set to... (Enforced)". Change this setting to Allow user to configure or Let user choose. Secondary Target: Work profile Look for a setting like Work profile notifications or Lock screen notifications. While this usually just controls lock screen visibility, if it's set to "Hide all notifications," it may interfere. Ensure it is set to Show all notification content or Allow user to configure. Click Save at the top or bottom of the page. This option is simply not there!
Factory reset protection (FRP) or enterprise factory reset protection (EFRP).
Hello, since Android 15 we have encountered a huge problem with Corporate phones (enrolled in BYOD) for which users leave the company without deleting their account. We therefore found ourselves with locked phones that we cannot return to our reseller (who asks us for a large sum to unlock them) so I come to you to find a solution or a tool available to the technical teams to clean up. We are open to any advice or helpNeed understand some point of this feature - 3.6. Managed configuration management
I have implemented this following feature - 3.6. Managed configuration management. Everything understand but got stuck in point - 3.6.3. The EMM's console must allow IT admins to set wildcards (such as $username$ or %emailAddress%) so that a single configuration for an app such as Gmail can be applied to multiple users. Not understand how to implement this wildcards in one policy for different devices and also let me know for gmail it is supported or not? Thanks in advance.
GSF ID not generated after device enrollment on Android 15
Hi everyone, We’re facing an issue with devices running Android 15 — after successfully enrolling them in our Android Enterprise setup (Device Owner / Fully Managed mode), the Google Services Framework (GSF) ID is not being generated. This issue did not occur on Android 13 or 14; the GSF ID was available immediately after enrollment. However, on Android 15, the GSF ID remains empty even after waiting and rebooting. We’ve already tried: Factory reset and re-enrollment Checking Google Play Services version Ensuring the device is connected to the internet Waiting for Play Store sync Despite that, the GSF ID is still missing. Could anyone confirm if there’s a known change in Android 15 related to GSF ID generation, or if additional permissions/configuration are required for enterprise-enrolled devices to obtain it? Any guidance or workaround would be greatly appreciated.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.
