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 + (userID % 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. 😀
