Calling Android Settings pages programmatically during Staging

In quite a few situations we need the user to input specific data during device Staging. For instance, I have been doing a job for a customer, requiring a PIN code pre-set on the device, when it comes back from repairs. This PIN code can only be set programmatically by Device Administrator class app (or MDM agent, which usually registers as one). Given the circumstances, this was not an option.

Normally, this means that you’d have to provide instruction containing lots of “tap this” and “skip that” as well as lots of screenshots to ensure that there is no way the user will be lost. However, this approach is error prone and time consuming. And for repair loop operations this means $$$. Wouldn’t it be better to just scan a barcode? But how?

Each page of the Settings app in an Activity. Thus, we can write an intent to pop it up. StageNow (via MX) allows us to run intents. The question is, how do we find, which data to populate the intent with? Let’s find out!

ADB logs (logcat or Android Monitor)

Usually, every time a new app is launched or a new Activity (window) pops up, there will be a message in the ADB log from ActivityManager – the service with a self-explanatory name. So, using Android Monitor, filtering with tag:ActivityManager we can track what is going on. In this case, however, things are a bit more difficult, as the Settings app does not call activities directly by name, using Intent Extras (think command line parameters instead).
AndrSettingsDump-001

OK, this is a dead end. We need a more fundamental approach. Trawling the Internet may surely help, but the problem is that every build of Android is very different, and what works on one device/OS may not work on another. We need something more universal.

Package dump

Fortunately, every Activity, Intent (and very much every other component) of an app must be registered with Android OS during installation via the Manifest file. I wrote already about manifest analysis, but for this case it is a bit too much. Since we have access to a live device, we can get the same data in a way that is a bit more user-friendly using the “dumpsys package” command.

>adb shell dumpsys package com.android.settings

This will produce a ~49KB (plain text!!!!) dump. Fortunately, we do not need all of it. In the very beginning on the dump there is something called “Activity Resolver Table”. This basically contains all possible types of Intents the app can process and the activities, to which those intents are directed. Now, some of them are pretty complicated, we need a section called “Non-Data Actions”. And in that section, we need to find an intent that will call up the password activity. Here is an example:

Non-Data Actions:
android.settings.DISPLAY_SETTINGS:
94efb52 com.android.settings/.Settings$DisplaySettingsActivity

So, if we send an intent with Action name android.settings.DISPLAY_SETTINGS we should see the Settings$DisplaySettingsActivity screen (Activity), which (hopefully) is all about changing display settings. Let’s try it out

>adb shell am start -a android.settings.DISPLAY_SETTINGS
Starting: Intent { act=android.settings.DISPLAY_SETTINGS }

Look and behold – a screen pops up!

AndrSettingsDump-002

Exploring further

Now, I want to warn you, that not everything you find in that table will work. Some settings may require permissions that you don’t have (try Fingerprint management), and thus will fail. Some are not implemented, and will thus fail. Some are not intended to be called without additional data, and will thus fail. But, still, there is a lot of stuff to play with. I have dumped the Settings app of our Zebra TC51 BSP 1.21.4-MG (Android M with GMS) and counted 112 different intents, some of which may call different screens depending on extra parameters!

Many of the intents have quite self-descripting names, such as IGNORE_BATTERY_OPTIMIZATION_SETTINGS or INPUT_METHOD_SETTINGS, but some are more obscure (android.bluetooth.devicepicker.action.LAUNCH).

For those obscure intents, or the ones that fail or require extras – try googling the CAPITALIZED part. In most cases you will end up in in a piece of Google’s own developer documentation such as below, explaining success conditions, extra data, permissions etc.

AndrSettingsDump-003

OK, so how about that PIN code?

The best I could find was android.app.action.SET_NEW_PASSWORD to bring up the Lock Screen configuration page. Note the android.app (Device Admin / Device Policy API) prefix, different from the standard android.settings – good luck figuring or googling those out, not knowing about package dumping!

I have then launched StageNow and created a simple barcode that invokes Intent CSP. Now, at the end of the staging routine, the user will be prompted to set the PIN on the device. Note that I only need to specify the action, everything else is on defaults.

AndrSettingsDump-004-5-6

A word of caution

Please keep in mind that MX does not have a “wait” instruction. If you need multiple steps at multiple pages, you will have to provide multiple barcodes. This is still faster and safer than tapping manually, though. For complex scenarios, custom apps of MDM scripts have to be developed, which, as I said before, was not an option for this job.

Summary

So, now you know

  • How to see which activity is in the foreground using the ADB logs (logcat or Android Monitor tool)
  • How to dump the package for ALL possible screens and processed intents
  • How to send an intent to launch a specific screen of the Settings app
  • How do find out more info about a specific intent
  • How to incorporate this into your StageNow routine
  • Some of the limitations of the process

A whole 6 points in a 3-page post! Cool, huh?

Do try this at home!

dumpsys package provides a lot more useful info about the app. Try finding these in the dump (save into a text file):

  • Basic things such as app name, version, APK location etc.
  • When was the app first installed and last updated.
  • Where the app files/code/data etc are located
  • App permissions
  • Which Services and Content Providers (essentially, provide access to app’s
    internal databases for external apps) does the app have

The End

Was this useful? Share your findings of useful Settings intents and package dump information in the comments!

One thought on “Calling Android Settings pages programmatically during Staging

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

<span>%d</span> bloggers like this: