Play Protect Blocking Custom DPC Apps — How to Get Approval or Alternatives?
Hi everyone, I'm a developer who helps enterprises build custom DPC (Device Policy Controller) Reference Documentation apps to manage Android devices based on their unique requirements. Recently, Play Protect has started blocking the installation of custom DPC apps, even when these apps are signed and used internally. The warning claims the app may pose a risk due to access to sensitive data - even though it's strictly for enterprise use. To make things more difficult: Google is no longer accepting registration of custom DPC apps with Android Enterprise, which limits official distribution and management options. Android Management APIs don’t support all use cases, and also have quote limit. I’ve applied twice to join the Android Enterprise portal to build a SaaS-based device management platform, but both requests were rejected without a clear reason. My questions for the community: Is there any official way to get a custom DPC app approved or whitelisted by Play Protect? Are there any alternative ways to manage Android devices at scale (outside of AMAPI or legacy EMM)? How can new developers or startups gain access to Android Enterprise features when onboarding is currently restricted? Any help, direction, or shared experience would be greatly appreciated. Thanks, KulwinderShare your deployment experiences with Android zero-touch enrollment
Hey everyone, In ‘5 Overlooked Benefits of Android Enterprise’, we touched on Android zero-touch enrollment, and it’s something many of you are actively using to streamline your device rollouts. For those in IT, Android zero-touch can be a powerful tool - see our handy guide to learn more. It’s about getting devices to your users ready to go, automatically enrolling in your EMM and pulling down all the right policies as soon as they connect. That means less hands-on time for your team and a smoother experience for end-users. We know real-world deployments always have their nuances, but it would be great to hear about your deployment experiences using zero-touch enrollment: Did you overcome any unexpected hurdles? What was the scale of your deployment - a few devices for new joiners, or hundreds for a company-wide refresh? If you could share one key tip or best practice for someone looking to nail their next zero-touch deployment, what would it be? We’re all here to learn from each other’s stories, and your insights are super valuable. I’m looking forward to reading your stories! Chat soon, Emilie
Request for Access to Android Enterprise Partner Portal Zero-touch Reseller Login
We are from Alphatech India and recently received a notification that our application to join the Carrier & Device Reseller Partner Program was declined. However, we would like to highlight that we are actively involved in large-scale deployments of Android-based mobile devices for enterprise customers across India. Access to the Android Enterprise Partner Portal, specifically the Zero-touch enrollment feature, is critical for us to streamline device provisioning and deliver a seamless experience to our clients. We request the community's guidance on how we can meet the eligibility requirements or explore any alternative process to gain access to the Zero-touch Reseller Portal. We are fully committed to meeting the necessary standards and are ready to provide any required documentation. Your support and direction on this matter would be greatly appreciated.Need Help with QR Enrollment for Multiple Devices in Educational Environment – Is External MDM Required?
Hi everyone, I'm managing a large number of Android tablets in an educational environment. I'm trying to enroll the devices using Android Enterprise with QR code enrollment, but I'm having trouble getting the QR method to appear. So far, only Zero-Touch shows as an option, but most of our devices were not purchased through Zero-Touch resellers, so we can't use that method. My main question is: Is it strictly necessary to use an external MDM (like Miradore, Intune, etc.) to generate the QR code, or is there a way to create and use it directly from the Google Admin console or natively through Android Enterprise? We want to deploy the tablets efficiently and avoid entering accounts manually. Ideally, each device would automatically enroll with our managed Google Play account by scanning a QR code after a factory reset. This is especially important in a school context, where we have many students and limited time for configuration. We are already registered in Google Workspace, and the tablets are in a dedicated organizational unit for students. The admin account is managed, and we are using the Android Enterprise platform linked to our domain. For reference, here are two YouTube videos showing the configuration steps I followed (which reflect our current setup): https://www.youtube.com/watch?v=jI-C_y1u8jE https://www.youtube.com/watch?v=h__pvfp559Q Any advice or clarification would be greatly appreciated. Especially if there’s a native way to enable QR enrollment without needing a full external MDM platform. Thanks in advance!
Issue with G Suite Apps Being Marked as Disabled in Play Store
Hi everyone, We are facing an issue where G Suite apps like Google Sheets, Google Drive, and Google Docs are installed on our managed devices, but when we check them in the Google Play Store, they appear as disabled. In some cases, the apps are randomly disabled, requiring manual re-enabling. We have verified: Google Device Policy settings Apps are approved and allowed in the managed Play Store Despite these checks, the issue persists across multiple devices with G Suite apps. Has anyone else experienced this issue? If so, do you know of any workarounds or if there is an ongoing Google-side issue causing this? For reference, I have attached a screenshot showing the issue. Looking forward to insights from the community! Thanks, Rupesh
Unable to start AE (Android Enterprise) Enrollment in Microsoft Intune MDM
We are currently using Microsoft Intune Mobile Device management solution to manage Android mobile devices, and these devices are currently enrolled in the mode of Android Device Administrator in Microsoft Intune. Google has deprecated Android device administrator management, continues to remove management capabilities, and no longer provides fixes or improvements. Intune will be ending support for Android device administrator management on devices with access to Google Mobile Services GMS beginning December 31, 2024. Hence, we're trying to setup Android Enterprise method of enrollment in Microsoft Intune. As part of pre-requisites in Intune, it's essential to connect Microsoft Intune account to managed Google play account. As per Microsoft recommendation, we are using Microsoft Entra account to connect to Google Play. After entering the Entra account username & password, authentication is redirecting to Google sign-in page and ending with below error. Someone at ABCD.com domain has already signed up Microsoft Intune Reference Article: https://learn.microsoft.com/en-us/mem/intune/enrollment/connect-intune-android-enterprise#connect-accounts Note: ABCD.com should be referred as domain name registered & verified in Microsoft Entra.
Silent installation of applications on TELPO devices using Android Enterprise
I have an Android application that I want to use on TELPO devices, but in a way that updates are downloaded silently on the device, meaning the user does not have to intervene to update or install an application. I understand that with the configurations offered by Android Enterprise, it is possible to set up a device to allow the actions I require.[Guide] First aid for bug reports
Hi! Mobile devices are quite complex and fast- changing. Errors sometimes sneak in and as a UEM administrator you often have to find a solution. If in doubt, the UEM manufacturer is the first point of contact, but if it is an app or OEM-specific error, a ticket to the right place can also speed up the solution. In addition, any support team will appreciate it if you look into the problem before creating a ticket, provide specific log files and perhaps even roughly narrow down the problem. But... How? The commands for logs and the sheer mass of log lines can be quite overwhelming! In this topic I would like to provide some information about logging for Android Enterprise, which will hopefully help some of you in the future. I will not cover all commands or segments in log files. If there is something that you think is important for logging, please feel free to add it. 😀 ADB - Android Debug Bridge Get the tools The ADB is a versatile command-line tool with which you can execute commands on a device. The adb and USB debugging on the mobile device are essential for detailed debugging. https://developer.android.com/tools/adb If you are not a developer, you do not need to install the entire Android Studio. The SDK Platform Tools are very useful and fully sufficient for logs. You can download the tools for Windows, Mac and Linux here: https://developer.android.com/tools/releases/platform-tools Prepare the device In order to access the device with the adb, “USB debugging” must be enabled. The setting can be found in the developer options, which are hidden by default. The build number must be tapped several times in the device settings until the message “You are now a developer!” appears. Now you can enable “USB debugging” in the developer options. The paths may vary depending on the OEM: Settings > About phone > (Software information) > Build number Settings > (System) > Developer Options > USB debugging Using the adb Check and select connected devices Navigate on your PC with the command line to the folder with the platform tools. With every adb command, the client checks whether the adb server process is running. If not, it will be started automatically. “adb devices” is useful as the first command. The adb server is started and already connected devices receive a query as to whether USB debugging should be trusted with this computer. PS C:\platform-tools> adb devices * daemon not running; starting now at tcp:5037 * daemon started successfully List of devices attached 3C261JEKB15011 unauthorized Trust the connection on the device: PS C:\platform-tools> adb devices List of devices attached 3C261JEKB15011 device You can use the -l option to display further device information. PS C:\platform-tools> adb devices -l List of devices attached 3C261JEKB15011 device product:akita model:Pixel_8a device:akita transport_id:1 If you need to connect multiple devices, you can use adb -s serialnumber to select a specific device for the command. This is not necessary if you have only connected one device. PS C:\platform-tools> adb -s 3C261JEKB15011 bugreport /data/user_de/0/com.android.shell/files/bugreports/bugrepo...le pulled, 0 skipped. 29.1 MB/s (13935432 bytes in 0.457s) Bug report copied to C:\platform-tools\bugreport-akita-AP4A.241205.013-2025-01-09-13-23-16.zip shell commands With adb shell you can execute commands on the device. You can find a more comprehensive overview of the commands here: https://developer.android.com/tools/adb#shellcommands device users With Android, features such as the Work Profile, Private Space or MultiUser functionality are separated using “User”. You can list which users are active on the device: PS C:\platform-tools> adb shell pm list users Users: UserInfo{0:Owner:4c13} running UserInfo{10:Work profile:1030} running UserInfo{11:Private space:1090} Android has multi-user support, where different people can use one device: https://developer.android.com/work/dpc/dedicated-devices/multiple-users This feature is optional for OEMs. For example, an OEM may have enabled multi-user for a tablet but disabled it for smartphones. The Work Profile is a special rule and does not fall under this limitation. Up to 3 additional users PS C:\platform-tools> adb shell pm get-max-users Maximum supported users: 4 No Multi-User support PS C:\platform-tools> adb shell pm get-max-users Maximum supported users: 1 list packages You can use adb shell pm list packages [options] filter to show the apps installed on the device and optionally filter them with options and text filters. Options: -f See associated file and file path -d Filter to only show disabled packages -e Filter to only show enabled packages -s Filter to only show system packages -3 Filter to only show third-party packages -i See the installer for the packages (e.g. com.android.vending = PlayStore) --user user_id The user space to query. Examples: Show non-system apps (/ manually installed) in Private Space PS C:\platform-tools> adb shell pm list packages -3 --user 11 package:org.bayton.packagesearch package:de.heise.android.heiseonlineapp Check whether an app has been sideloaded in the personal space PS C:\platform-tools> adb shell pm list packages -3 --user 0 -i package:com.airwatch.androidagent installer=com.android.vending package:com.maxrave.simpmusic installer=com.google.android.packageinstaller package:com.google.android.keep installer=com.android.vending Show the full path of system apps that have “manager” in their name “priv-app” in the file path is an indicator that the app has privileged permissions. https://source.android.com/docs/core/permissions/perms-allowlist PS C:\platform-tools> adb shell pm list packages -s -f manager package:/system_ext/priv-app/StorageManagerGoogle/StorageManagerGoogle.apk=com.google.android.storagemanager package:/product/overlay/CompanionDeviceManager__nosdcard__auto_generated_characteristics_rro.apk=com.android.companiondevicemanager.auto_generated_characteristics_rro package:/product/overlay/StorageManagerGoogle__akita__auto_generated_rro_product.apk=com.google.android.storagemanager.auto_generated_rro_product__ package:/system_ext/priv-app/ConnectivityThermalPowerManager/ConnectivityThermalPowerManager.apk=com.google.android.connectivitythermalpowermanager package:/system/app/CompanionDeviceManager/CompanionDeviceManager.apk=com.android.companiondevicemanager package:/vendor/overlay/StorageManagerGoogle__akita__auto_generated_rro_vendor.apk=com.google.android.storagemanager.auto_generated_rro_vendor__ package:/system/priv-app/CredentialManager/CredentialManager.apk=com.android.credentialmanager Screen recordings You can take a screenshot or video via adb and then copy it to your computer. With high display resolutions, the resolution and bit rate should be reasonably reduced for video recordings so that the recordings do not become too large. Take and transfer a screenshot with adb shell screencap filename and adb pull path/file. PS C:\platform-tools> adb shell screencap /sdcard/screenshot.png | adb pull /sdcard/screenshot.png /sdcard/screenshot.png: 1 file pulled, 0 skipped. 31.3 MB/s (1760513 bytes in 0.054s) Videos can be recorded with adb shell screenrecord [options] filename. Options: --size widthxheight Define video size. (Default = display resolution) --bit-rate rate Set the video bit rate for the video in megabits/second. (Default = 20Mbps) --time-limit seconds Set the maximum recording time up to maximum of 180 seconds --verbose Display log information on the command-line screen. Example for half display resolution, 6Mbps and the display of log information PS C:\platform-tools> adb shell screenrecord --size 540x1200 --bit-rate 6000000 --verbose /sdcard/video.mp4 Display is 1080x2400 @60.00fps (orientation=ROTATION_0), layerStack=0 Configuring recorder for 540x1200 video/avc at 6.00Mbps Content area is 540x1200 at offset x=0 y=0 PS C:\platform-tools> adb pull /sdcard/video.mp4 /sdcard/video.mp4: 1 file pulled, 0 skipped. 3.2 MB/s (20353 bytes in 0.006s) Bug Report The bug report is a collection of various system services and logs. This report shows the status of the device quite comprehensively and is my first port of call when there are problems with managed devices. You should create the bug report as soon as the error has been reproduced. Often only the last 15 minutes are saved in the log buffer. The bug report contains several files, but the most interesting is a text file, which can quickly get 100MB in size and has over a million lines of content. As a rule, the text file begins with “bugreport” (or sometimes “dumpstate”) and ends with the creation date of the report. Generate bug report via adb and save it on the PC: PS C:\platform-tools> adb bugreport /data/user_de/0/com.android.shell/files/bugreports/bugreport-akita-AP4A.24120...-10-57-21.zip: 1 file pulled, 0 skipped. 25.2 MB/s (15330123 bytes in 0.581s) Bug report copied to C:\platform-tools\bugreport-akita-AP4A.241205.013-2025-01-10-10-57-21.zip A bug report can also be started manually in the developer options on the device. You can use the adb to search for bug reports on the device and copy them specifically from the device. PS C:\platform-tools> adb shell ls /bugreports/ bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06-dumpstate_log-5164.txt bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06.zip bugreport-akita-AP4A.241205.013-2025-01-09-13-23-16-dumpstate_log-31790.txt bugreport-akita-AP4A.241205.013-2025-01-09-13-23-16.zip bugreport-akita-AP4A.241205.013-2025-01-10-10-57-21-dumpstate_log-5743.txt bugreport-akita-AP4A.241205.013-2025-01-10-10-57-21.zip dumpstate-stats.txt PS C:\platform-tools> adb pull /bugreports/bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06.zip /bugreports/bugreport-akita-AP3A.241005.015-2024-10-22-11-38-06.zip: 1 file pulled, 0 skipped. 29.1 MB/s (15931073 bytes in 0.521s) For Samsung devices, you can also generate extensive logs from the device using SysDump. This includes the bug report and even more logs, some of which are OEM-specific: https://docs.samsungknox.com/admin/knox-platform-for-enterprise/troubleshoot/get-device-logs/ logcat If you have problems with a specific app and no diagnostic data can be sent from the app itself, the logcat log will help you. Although logcat logs are also available in the bug report, experience has shown that some verbose and info logs from individual apps are not available there. With a bug report and a separately recorded logcat, you are very well prepared for troubleshooting. The default parameters for logcat are usually sufficient. PS C:\platform-tools> adb logcat > logcat.txt PS C:\platform-tools> adb logcat -v threadtime -b main -b system -b crash *:V > logcat.txt The two commands should provide the same output. By default, you already get a good output format, relevant buffers and everything from verbose logs upwards. -v threadtime -v Defines the output format. threadtime = Date, Time, Priority, Tag, PID, TID, message -b main -b system -b crash There are different log buffers for log messages. main,system,crash are default. There are radio,events,main,system,crash and all. *:V All logs with verbose or higher are displayed An example in which the events are displayed in the command line, color-coded from the debug level upwards for a specific PID (ProcessID) PS C:\platform-tools> adb logcat -v color --pid=16095 *:D Depending on your needs, you can experiment with logcat and read more in the official documentation. https://developer.android.com/tools/logcat Find your way through the bug report The bug report usually has over a million lines and is therefore not something you can simply scroll back and forth through manually. It is helpful if you know the rough structure and know what to look for. The bug report has three main sections: dumpstate dumpsys logcat Logcat Log Level Android has the following log levels: V Verbose (lowest priority) D Debug I Info W Warning E Error F Fatal S Silent (highest priority, never used for output) While verbose logs are intended to help you understand the functionality of apps, warnings and errors indicate a problem. However, some errors can often be ignored. If, for example, you have problems with apps that are terminated unexpectedly by the operating system, you will quickly find suitable logs in the bug report. This is because fatal exceptions occur rather rare. There is a noticeable backtrace in the logs, especially when apps are terminated by the OS. https://source.android.com/docs/core/tests/debug/native-crash The Logcat uses the buffers crash, system and main by default. You can jump to the respective one by jumping to “beginning of buffername”. Without having gone deep into troubleshooting, you may already encounter relevant logs at the “beginning of crash” that have recorded the problem. You will find logs for processes that do not belong to the OS under “beginning of main”. --------- beginning of crash 07-14 22:22:03.272 +0000 22979 23472 E AndroidRuntime: FATAL EXCEPTION: Analytics-HighPri-Proc 07-14 22:22:03.272 +0000 22979 23472 E AndroidRuntime: Process: com.facebook.appmanager, PID: 22979 --------- beginning of system 07-31 10:39:57.225 +0000 1220 1750 W ActivityManager: Slow operation: 90ms so far, now at startProcess: done updating battery stats 07-31 10:39:57.225 +0000 1220 1750 W ActivityManager: Slow operation: 90ms so far, now at startProcess: building log message --------- beginning of main 08-01 05:46:02.401 +0000 29231 29231 I AirWatch_VmwareSDKWHAccessController: disabled work hour restrictions on VMware SDK 08-01 05:46:02.401 +0000 29231 29231 I AirWatch_HubFeatures: Work hour restrictions feature toggled by user to UNAVAILABLE Dumpstate The bug report starts with the Dumpstate and shows detailed information on the hardware, software, network and system-related error logs. Right at the beginning of the log you can see when the Dumpstate was performed, which device model it is and which software build is installed. It also contains “netstat -nW”, for example, if you want to check the network connections at the time of the report. Dumpsys Information on all system and subcomponents is recorded in dumpsys. The dumpsys is a large part of the dump state. A few of the service dumps are very interesting for managed devices. DUMP OF SERVICE user This service dump shows all the details of the Android users. You can see whether a Work Profile (User10) or Personal Space (User11) has been set up. Users can have restrictions. For example, that no guest accounts (MultiUser) can be set up or that the Work Profile may not be removed. DUMP OF SERVICE account The service dump for accounts shows which accounts are set up for which user. This includes, for example, the automated Google account that is required for administration with Android Enterprise. DUMP OF SERVICE device_policy In the service dump for device_policy, you can see which applications are allowed to set and change policies. You can also check which policies have been set and which DPC is active. DUMP OF SERVICE package The dump for packages is very large! It has a Intent Resolution Table, lists which apps react to which MIME types or which permissions are used by which apps. Extensive data is also displayed for each app. These include, for example: appId, versionName, lastUpdateTime, declared / install permissions, install status / hidden app per user, etc. To find the relevant app quickly, you should search for “Package [packagename]” in the bug report. appId / UID / PID / TID There are various IDs that are associated with apps. The logcat in the bug report uses UID, PID and TID after the date. Unfortunately, only the PID and TID are displayed in the adb logcat. It can therefore be helpful to search for the UID and PIDs for an app if you want to trace an app error. Example: 01-10 10:58:57.522 1010269 16095 16095 I AirWatchVPN: PUM: Sending update request appId The Id for an installed app that can be found in the DUMP OF SERVICE package. Package [com.android.chrome] (db6f3db): appId=10197 UID The UID is a specific ID for an app per user. If an app is used by several users, the UID differs for each user. The UID is calculated like this: UID = User * 100000 + (appID % 100000) If Chrome is used in the personal space (User0), Work Profile (User10) and PrivateSpace (User11), there are the UIDs 10197, 1010197 and 1110197. Instead of calculating, you can also simply chain the UserId with the appId 10 “+” 10197 = 1010197 for the Work Profile PID (process ID) The DumpSys contains a mapping of all ProcessIDs under “PID mappings:”. PID mappings: PID #28694: ProcessRecord{c8faf8d 28694:com.android.chrome/u10a197} In this case, Chrome has the PID 28694 in the Work Profile at the time of the dump state. TID (ThreadID) If a process has only one thread, the TID is identical to the PID. If a process uses multiple threads, different TIDs will be used. Record the exact time of errors To avoid having to view a logcat entirely, you should make a note of exactly when an error occurred. If you don't want to make extra notes, you can also use the power status of the screen for this purpose The logcat records when the display is switched off or on. At 0 it is off, at 1 it is switched on. 01-10 10:30:45.863 1000 1678 1678 I screen_toggled: 1 01-10 10:33:48.081 1000 1678 1678 I screen_toggled: 0 01-10 10:38:41.860 1000 1678 1678 I screen_toggled: 1 01-10 10:43:32.290 1000 1678 1678 I screen_toggled: 0 Final Thoughts Depending on the cause of the error, troubleshooting can take different amounts of time and effort. An app that does not trust a TLS connection is easier to isolate than a bug in Android or a possibly faulty implementation by an OEM. I personally use Notepad++ to mark relevant package names, UIDs, PIDs and messages and was usually able to recognize the approximate cause. If anyone has more tricks in the area of bug reports or knows good tools for analyzing them, that would be very interesting. 😀
What are some underrated Android features users should try?
What are some cool but underrated Android Features on Android that most people don’t know about? those little things that make life easier but don’t get talked about much. I feel like there’s so much hidden stuff in Android that we miss out on.
Publishing the same app on multiple MDM, EMM Solutions
Hello All, We assist the underprivileged and are attempting to distribute our application to students who have been provided with EMM-enabled Android devices by the government. However, we've encountered a problem while trying to publish our application on the EMM platform; it's generating the following error: "The package name '*****************' is already in use by another application." In seeking advice on this matter, I received the following feedback: If the EMM platform utilizes a public/private Play Store, they share the same library and for large-scale deployments, the EMM provider should register with an enterprise Play Store. This would allow them to publish any application within their ecosystem without conflicts arising from the general domain. Could anyone confirm if this information is accurate? I would appreciate some insights on this issue. Regards,
