Welcome to the new site! It was the reason I didn’t post anything, as I was busy building up the new site and migrating content to it. With this post, I continue to look into the issues faced with fully managed Android Enterprise devices. Like any other enterprise, we
Welcome to the new site! It was the reason I didn’t post anything, as I was busy building up the new site and migrating content to it.
With this post, I continue to look into the issues faced with fully managed Android Enterprise devices. Like any other enterprise, we also enroll and distribute these devices to our user base. However, since we started rolling out these devices, the feedback from the user community was not that good.
Users reported that they are not happy with the performance of their phones. M365 apps like Outlook, Teams, and PowerApps were opening very slowly. Initially, we assumed a particular phone model was slow, but even high-end phones reported similar behavior.
Troubleshooting was not easy as it required a deeper level of troubleshooting and parallelly learning to debug Android devices. It involved comparing performances for all possible enrollment scenarios, i.e., Fully Managed User Device; Corporate Owned – Dedicated Device; Corporate Owned – Work Profile; Personal Owned – Work Profile.
In an Android enterprise deployment, an enterprise maintains control over various aspects of user devices, such as isolating work-related information from users’ personal data, pre-configuring approved apps for the environment, or disabling device capabilities (for example, the camera).
The DPC creates and manages the work profile on the device on which it is installed. The work profile encrypts work-related information and keeps it separate from the user’s personal apps and data. Before creating the work profile, the DPC can also provision a managed Google Play Account for use on the device.
When a device is enrolled in an MDM, it uses the Device Policy Controller (DPC), which is automatically installed during enrollment. The DPC app can be accessed by navigating to Google Play and selecting and opening the Android Device Policy app. You can sync the device, view which apps were installed, and policy settings.
Enable developer options on the Android device:
Once everything is in place, 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.
Open a command prompt and navigate to the directory where the SDK was installed and follow the below steps:
Type in adb.exe devices -l, and you should see your Android device listed:
If you don’t see the device or receive any error message, then run the following commands:
adb kill-server
adb start-server
and then try again with adb.exe devices -l
You will need to collect logcat and dumpsys logs from the connected devices.
Logcat is a command-line tool that dumps a log of system messages, including stack traces when the device throws an error and messages that you have written from your app with the Log class
From the command prompt, run the following command with replicating the slowness issue/behavior on the connected device :
adb.exe logcat -v threadtime [device ID] > C:\temp\fully_managed.log
A few weeks back, I have written a post on the Android reboot issue, and it has step-by-step instructions for collecting dumpsys logs.
Android device logs 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.
However, I recommend that before you start reading the logs, you go through Google Documents for developers, as it will help you familiarize yourself with these queries and the logs.
Let’s get started and dig through the logs for some useful info.
The logcat I just exported from the device is around 40MB, and I am using Android Studio to open it.
This log file will have a lot of information with all the details of what is going on with the device. But for now, I am more interested in finding out what is causing the M365 apps to go unresponsive.
There are multiple ways to look for this info, either you go line-by-line through the log file – which will take days as it has thousands of lines with details of numerous processes & services, or the smart way by looking directly for impacted processes.
You have to export the list of all apps installed on the device (hidden or not) run so that you have the data to look for:
In the command prompt, execute the below command:
adb.exe pm list packages -s >C:\temp\fully_managed_packages.log
I found that Microsoft Apps are the top memory-intensive apps in this log file. Now with this info, I just need to filter out the logcat log for these packages.
The logs had consistent entries for connections getting dropped for M365 apps. Whenever the device-based sign-in was attempted, the query failed.
The ADAL may generate this error message whenever any application(M365 apps) cannot communicate with the broker application (Microsoft Authenticator or Company Portal). You might also see error messages like “BROKER_AUTHENTICATOR_NOT_RESPONDING“. This is well documented by Microsoft that it is due to the OEM limiting inter-app communication on their hardware.
The bound service is expected to perform an interactive and silent auth for ADAL in brokered scenarios. If this communication between ADAL and brokers fails, ADAL will return the “connection refused” back to the app. In silent authentication scenarios, this fails to get a token. This will result in an error in interactive authentication scenarios even before the user sees a prompt.
Several device manufacturers are impacted by this issue, including Samsung, Huawei, OnePlus, and Vivo. It’s generally built-in in the devices exposing battery settings but often is only exposed in a subset of the OEM’s device lineup.
It depends on OEMs on how they allow the end users to limit the operating system’s ability to launch secondary apps. Each device may expose a different setting to do this.
In this case, it is related specifically to M365 apps such as Outlook, Power Apps & OneDrive, and these apps require background activity, so the users need to configure the Battery Optimization settings on their devices:
1. Go to Settings on your Android device
2. Search for Apps and tap on them
3. Search for the app having an issue and Tap on that app
4. Now, search for Battery and top on it.
5. Turn the switch ON for “Allow background activity”
6. Tap “Optimise battery usage” and turn Switch OFF for the app having an issue.
7. In case you don’t find the app, from the top select All rather than “Apps not optimized”.
Also, the Adaptive battery settings under Device Care app > More battery settings has to be disabled – in case there are apps that user use often and still don’t want to avoid disconnection issues.
After making these changes, you will notice an improvement in the device performance, and if you go through the device logs, you will not find these errors anymore. However, as these settings allow the app to run in the background without battery optimization, users may receive a prompt on their devices to switch on the battery optimization. This prompt needs to be ignored!
That’s all for today..have a great weekend..cheers 🍻🥂
