In the last few days, many people have complained about the strange behavior of their Android Enterprise Devices, wherein the user’s devices suddenly reboot on their own. I also faced the same issue with one of my customers, and it was hard to find what made the devices go crazy. Continue reading this blog post to find the reason for the sudden restarts with the steps to fix them.
As these devices are being managed through Intune, so first thought was to check for the maintenance window in Intune for the impacted profiles.
This looks good as it is expected that the device can reboot between 00:00 & 05:00, but the problem was that devices were unexpectedly rebooting outside this window. The problem started with only a couple of users, and eventually, every user reported the sudden restarts, and we were clueless.
Get device logs
When you are experiencing anything strange with your devices, the first thing you should do is export the logs.
1. In the Phone Application, enter *#9900#
2. Set the Debug Level to Mid.
3. Wait for the device to restart.
4. Open the app you want to debug and reproduce your issue.
5. After reproducing your issue, enter *#9900# again in the Phone Application
6. Select Run dumpstate/logcat
7. Select Copy to sd card Navigate to the log directory created on the device using the My Files app or a Windows PC with a USB cable connection.
8. After you have finished, follow steps 1-3 again, delete dumpstate/logcat and return the Debug Level to low.
Step 1: Enable developer options on the Android device:
- Go to Settings -> About phone.
- Tap the Build number button seven (7) times.
- Return to the previous screen to find Developer Options at the bottom. The Developer Options screen might be located or named differently on some devices.
- Open the Developer Options page and scroll down until you find USB Debugging and toggle it to Enabled.
- Once complete, connect a USB cable from your PC to the device. If this is the first time the device has been connected, a popup will appear asking if it’s OK to allow debugging. Select Allow and select the box to Always allow.
- This will enable a connection between your computer and the connected Android device.
Step 2: Collect the ADB log through a windows machine:
- Navigate to https://developer.android.com/studio/releases/platform-tools#downloads.
- Select Download SDK platform -> Tools for Windows.
- Unzip the downloaded package.
- Open a Command Prompt as administrator (Run as administrator).
- Type cd “<location of unzipped package>.” It should look something like this:
6. Run the following command in the ADB console to enable verbose logging (single line):
adb logcat -G 32M; adb shell setprop persist.log.tag.dpcsupport VERBOSE; adb shell
setprop persist.log.tag.clouddpc VERBOSE; adb shell setprop persist.log.tag.Finsky
VERBOSE; adb shell setprop persist.log.tag.Auth VERBOSE; adb shell setprop
persist.log.tag.Volley VERBOSE; adb shell setprop persist.log.tag.PackageManager
7. adb devices <—- Copy the device ID.
8. Run adb -s “<paste device id>” bugreport <path for copying the bug report on your PC
adb -s abc123xyz bugreport E:\bugreport
Read Device Logs
Android bug reports are not that hard to read as they are in .txt format. The logs exported in the previous step will have information like app crashes, deadlocks, activities, memory & CPU utilization, power consumption, etc.
For now, we will only focus on ANR (Application Not Responding) & Deadlocks and Power, as this will give us the details of the apps that are crashing and causing unexpected system reboots.
From these logs, you will identify that “vending(Play Store)” is causing most of the reboots. On a detailed analysis of the logs, you will also see “mainline_update” as a reboot cause. This “mainline_update” is a request for a reboot due to an update of the Google main line, which is triggered by “vending(Play Store)” when there is a pkg to update.
There were EIGHT (8) mainline APKs for which update failed, then rollback occurred, and this caused a reboot. That’s why reboot occurs.
The best way to get this fixed is to add the identified problematic mainline APKs in Intune by creating these applications in Intune and deploying them to affected devices. It could be that, in your case, different APKs are causing this.
[ mainline APKs identified in the ANR logs]
Enable a System App in Intune
Let’s add these APKs as system apps and deploy them to the group of affected devices:
1. Sign in to the Microsoft Endpoint Manager admin center.
2. Select Apps > All apps > Add.
3. In the Select app type pane, select Android Enterprise System App from the available options, and click Select.
4. On the App information page, add the app details:
- App Name: Enter the name of the app.
- Publisher: Enter the name of the publisher of the app.
- Package Name: Enter a package name. Intune will validate that the package name is valid.
5. Assign the app to the required group.
6. Repeat the same steps for adding the mainline APKs.
This will not install any app but will whitelist the mentioned APKs, and the devices should no longer reboot on their own. Once you have verified that this is working, you can create a dynamic group of all Android Enterprise Devices and assign these apps to that group).