Show how to use pm command
Show how to use pm command
ADB Shell Commands
In this document
The Android Debug Bridge (adb) provides a Unix shell that you can use to run a variety of commands on an emulator or connected device. The command binaries are stored in the file system of the emulator or device, at /system/bin/.
Issuing Shell Commands
You can use the shell command to issue commands, with or without entering the adb remote shell on the emulator/device. To issue a single command without entering a remote shell, use the shell command like this:
Or enter a remote shell on an emulator/device like this:
Using activity manager (am)
Within an adb shell, you can issue commands with the activity manager ( am ) tool to perform various system actions, such as start an activity, force-stop a process, broadcast an intent, modify the device screen properties, and more. While in a shell, the syntax is:
You can also issue an activity manager command directly from adb without entering a remote shell. For example:
Table 2. Available activity manager commands
(the app’s package name).
(the app’s package name). This command kills only processes that are safe to kill and that will not impact the user experience.
.
Example:
am display-size 1280×800
Example:
am display-density 480
See the Specification for arguments.
Specification for arguments
For activity manager commands that take a argument, you can specify the intent with the following options:
You can directly specify a URI, package name, and component name when not qualified by one of the above options. When an argument is unqualified, the tool assumes the argument is a URI if it contains a «:» (colon); it assumes the argument is a component name if it contains a «/» (forward-slash); otherwise it assumes the argument is a package name.
Using package manager (pm)
Within an adb shell, you can issue commands with the package manager ( pm ) tool to perform actions and queries on application packages installed on the device. While in a shell, the syntax is:
You can also issue a package manager command directly from adb without entering a remote shell. For example:
Table 3. Available package manager commands.
.
Note: This is only intended for debugging; using this can cause applications to break and other undesireable behavior.
Taking a device screenshot
The screencap command is a shell utility for taking a screenshot of a device display. While in a shell, the syntax is:
To use the screencap from the command line, type the following:
Here’s an example screenshot session, using the adb shell to capture the screenshot and the pull command to download the file from the device:
Recording a device screen
The screenrecord command is a shell utility for recording the display of devices running Android 4.4 (API level 19) and higher. The utility records screen activity to an MPEG-4 file.
Note: Audio is not recorded with the video file.
A developer can use this file to create promotional or training videos. While in a shell, the syntax is:
To use screenrecord from the command line, type the following:
To begin recording your device screen, run the screenrecord command to record the video. Then, run the pull command to download the video from the device to the host computer. Here’s an example recording session:
The screenrecord utility can record at any supported resolution and bit rate you request, while retaining the aspect ratio of the device display. The utility records at the native display resolution and orientation by default, with a maximum length of three minutes.
There are some known limitations of the screenrecord utility that you should be aware of when using it:
Table 4. screenrecord options
Other shell commands
For a list of all the available shell programs, use the following command:
Help is available for most of the commands.
Table 5 lists some of the more common adb shell commands.
Table 5. Some other adb shell commands
Android Debug Bridge (ADB) Commands Manual
Within an adb shell, you can issue commands with the package manager (pm) tool to perform actions and queries on app packages installed on the device. You can issue a package manager command directly from adb without entering a remote shell. For example:
Command
Prints all known permission groups.
List all test packages. Options:
Prints all features of the system.
Prints all the libraries supported by the current device.
Prints all users on the system.
Installs a package (specified by path ) to the system. Options:
Removes a package from the system. Options:
Deletes all data associated with a package.
Enable the given package or component (written as «package/class»).
Disable the given package or component (written as «package/class»).
Grant a permission to an app. On devices running Android 6.0 (API level 23) and higher, the permission can be any permission declared in the app manifest. On devices running Android 5.1 (API level 22) and lower, must be an optional permission defined by the app.
Revoke a permission from an app. On devices running Android 6.0 (API level 23) and higher, the permission can be any permission declared in the app manifest. On devices running Android 5.1 (API level 22) and lower, must be an optional permission defined by the app.
Changes the default install location. Location values:
Note: This is only intended for debugging; using this can cause apps to break and other undesireable behavior.
Returns the current install location. Return values:
Specifies whether the given permission should be enforced.
Trim cache files to reach the given free space.
Prints the maximum number of users supported by the device.
Android Debug Bridge
In this document
Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:
When you start an adb client, the client first checks whether there is an adb server process already running. If there isn’t, it starts the server process. When the server starts, it binds to local TCP port 5037 and listens for commands sent from adb clients—all adb clients use port 5037 to communicate with the adb server.
The server then sets up connections to all running emulator/device instances. It locates emulator/device instances by scanning odd-numbered ports in the range 5555 to 5585, the range used by emulators/devices. Where the server finds an adb daemon, it sets up a connection to that port. Note that each emulator/device instance acquires a pair of sequential ports — an even-numbered port for console connections and an odd-numbered port for adb connections. For example:
Emulator 1, console: 5554
Emulator 1, adb: 5555
Emulator 2, console: 5556
Emulator 2, adb: 5557
and so on.
As shown, the emulator instance connected to adb on port 5555 is the same as the instance whose console listens on port 5554.
Once the server has set up connections to all emulator instances, you can use adb commands to access those instances. Because the server manages connections to emulator/device instances and handles commands from multiple adb clients, you can control any emulator/device instance from any client (or from a script).
Syntax
You can issue adb commands from a command line on your development machine or from a script. The usage is:
Commands
The table below lists all of the supported adb commands and explains their meaning and usage.
Table 1. Available adb commands
Note that you should not automatically start a PPP connection.
Querying for Emulator/Device Instances
Before issuing adb commands, it is helpful to know what emulator/device instances are connected to the adb server. You can generate a list of attached emulators/devices using the devices command:
In response, adb prints this status information for each instance:
The output for each instance is formatted like this:
Here’s an example showing the devices command and its output:
Directing Commands to a Specific Emulator/Device Instance
As shown, you specify the target instance for a command using its adb-assigned serial number. You can use the devices command to obtain the serial numbers of running emulator/device instances. For example:
Note that, if you issue a command without specifying a target emulator/device instance while multiple devices are available, adb generates an error.
Installing an Application
Note that, if you are using the Eclipse IDE and have the ADT plugin installed, you do not need to use adb (or aapt) directly to install your application on the emulator/device. Instead, the ADT plugin handles the packaging and installation of the application for you.
Forwarding Ports
You can use the forward command to set up arbitrary port forwarding — forwarding of requests on a specific host port to a different port on an emulator/device instance. Here’s how you would set up forwarding of host port 6100 to emulator/device port 7100:
You can also use adb to set up forwarding to named abstract UNIX domain sockets, as illustrated here:
Copying Files to or from an Emulator/Device Instance
You can use the adb commands pull and push to copy files to and from an emulator/device instance. Unlike the install command, which only copies an APK file to a specific location, the pull and push commands let you copy arbitrary directories and files to any location in an emulator/device instance.
To copy a file or directory (and its sub-directories) from the emulator or device, use
To copy a file or directory (and its sub-directories) to the emulator or device, use
In the commands, and refer to the paths to the target files/directory on your development machine (local) and on the emulator/device instance (remote). For example:
Issuing Shell Commands
Adb provides a Unix shell that you can use to run a variety of commands on an emulator or connected device. The command binaries are stored in the file system of the emulator or device, at /system/bin/.
Two of the most common command tools are activity manager ( am ) and package manager ( pm ).
You can use the shell command to issue commands, with or without entering the adb remote shell on the emulator/device. To issue a single command without entering a remote shell, use the shell command like this:
Or enter a remote shell on an emulator/device like this:
Using activity manager (am)
Within an adb shell, you can issue commands with the activity manager ( am ) tool to perform various system actions, such as start an activity, force-stop a process, broadcast an intent, modify the device screen properties, and more. While in a shell, the syntax is:
You can also issue an activity manager command directly from adb without entering a remote shell. For example:
Table 2. Available activity manager commands
(the app’s package name).
(the app’s package name). This command kills only processes that are safe to kill and that will not impact the user experience.
.
Example:
am display-size 1280×800
Example:
am display-density 480
See the Specification for arguments.
Specification for arguments
For activity manager commands that take a argument, you can specify the intent with the following options:
You can directly specify a URI, package name, and component name when not qualified by one of the above options. When an argument is unqualified, the tool assumes the argument is a URI if it contains a «:» (colon); it assumes the argument is a component name if it contains a «/» (forward-slash); otherwise it assumes the argument is a package name.
Using package manager (pm)
Within an adb shell, you can issue commands with the package manager ( pm ) tool to perform actions and queries on application packages installed on the device. While in a shell, the syntax is:
You can also issue a package manager command directly from adb without entering a remote shell. For example:
Table 3. Available package manager commands.
.
Note: This is only intended for debugging; using this can cause applications to break and other undesireable behavior.
Examining sqlite3 databases from a remote shell
Here’s an example:
UI/Application Exerciser Monkey
The Monkey is a program that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events. You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner.
The simplest way to use the monkey is with the following command, which launches your application and sends 500 pseudo-random events to it.
For more information about command options for Monkey, see the complete UI/Application Exerciser Monkey documentation page.
Other shell commands
For a list of all the available shell programs, use the following command:
Help is available for most of the commands.
Table 4 lists some of the more common adb shell commands.
Table 4. Some other adb shell commands
| Shell Command | Description | Comments |
|---|---|---|
| dumpsys | Dumps system data to the screen. | The Dalvik Debug Monitor Server (DDMS) tool offers integrated debug environment that you may find easier to use. |
| dumpstate | Dumps state to a file. | |
| logcat [option]. [filter-spec]. | Enables system and app logging and prints output to the screen. | |
| dmesg | Prints kernel debugging messages to the screen. | |
| start | Starts (restarts) an emulator/device instance. | |
| stop | Stops execution of an emulator/device instance. |
Enabling logcat logging
The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command.
You can use the logcat command to view and follow the contents of the system’s log buffers. The general usage is:
You can use the logcat command from your development computer or from a remote adb shell in an emulator/device instance. To view log output in your development computer, you use
and from a remote adb shell you use
See Reading and Writing Logs for complete information about logcat commend options and filter specifications.
Stopping the adb server
In some cases, you might need to terminate the adb server process and then restart it. For example, if adb does not respond to a command, you can terminate the server and restart it and that may resolve the problem.
To stop the adb server, use the kill-server command. You can then restart the server by issuing any other adb command.
Understanding App Permissions
By default, an Android app starts with zero permissions granted to it. When the app needs to use any of the protected features of the device (sending network requests, accessing the camera, sending an SMS, etc) it must obtain the appropriate permission from the user to do so.
Before Marshmallow, permissions were handled at install-time and specified in the AndroidManifest.xml within the project. Full list of permissions can be found here. After Marshmallow, permissions must now be requested at runtime before being used. There are a number of libraries available to make runtime permissions easier. If you to get started quickly, check out our guide on managing runtime permissions with PermissionsDispatcher.
Permissions were much simpler before Marshmallow (API 23). All permissions were handled at install-time. When a user went to install an app from the Google Play Store, the user was presented a list of permissions that the app required (some people referred to this as a «wall of permissions». The user could either accept all the permissions and continue to install the app or decide not to install the app. It was an all or nothing approach. There was no way to grant only certain permissions to the app and no way for the user to revoke certain permissions after the app was installed.
Example of pre-Marshmallow permissions requested by the Dropbox app:
For an app developer, permissions were very simple. To request one of the many permissions, simply specify it in the AndroidManifest.xml :
For example, an application that needs to read the user’s contacts would add the following to it’s AndroidManifest.xml :
That’s all there was to it. The user had no way of changing permissions, even after installing the app. This made it easy for developers to deal with permissions, but wasn’t the best user experience.
Marshmallow brought large changes to the permissions model. It introduced the concept of runtime permissions. These are permissions that are requested while the app is running (instead of before the app is installed). These permission can then be allowed or denied by the user. For approved permissions, these can also be revoked at a later time.
This means there are a couple more things to consider when working with permissions for a Marshmallow app. Keep in mind that your targetSdkVersion must be >= 23 and your emulator / device must be running Marshmallow to see the new permissions model. If this isn’t the case, see the backwards compatibility section to understand how permissions will behave on your configuration.
Important: Normal Permissions must be added to the AndroidManifest :
If the permission you need to add isn’t listed under the normal permissions, you’ll need to deal with «Runtime Permissions». Runtime permissions are permissions that are requested as they are needed while the app is running. These permissions will show a dialog to the user, similar to the following one:
The first step when adding a «Runtime Permission» is to add it to the AndroidManifest :
Permission Groups avoids spamming the user with a lot of permission requests while allowing the app developer to only request the minimal amount of permissions needed at any point in time.
Related permissions are grouped into one of the permission groups. When an app requests a permission that belongs to a particular permission group (i.e. READ_CONTACTS), Android asks the user about the higher level group instead (CONTACTS). This way when the app later needs the WRITE_CONTACTS permission, Android can automatically grant this itself without prompting the user.
In most of your interaction with the permission API’s you’ll be working with the individual permissions and not the permission groups, but pay close attention to what the API expects as both permissions and permission groups are Strings.
There are 2 main scenarios to think about when it comes to backwards compatibility:
Google recommends in this video that there are four patterns to consider when thinking about permissions:
Each pattern dictates a different way of requesting permissions. For instance, when requesting for critical but unclear permissions, use a warm welcome screen to help understand a permission is requested. For critical permissions, such as a camera app that needs camera permission, ask up-front for it. Secondary features can be requested later in context, such as a geotagging app when asking for a location permission. For permissions that are secondary and unclear, you should include a rationale explanation if you really need them.
Rethink about whether you need read/write storage permissions (i.e. android.permission.WRITE_EXTERNAL_STORAGE or android.permission.READ_EXTERNAL_STORAGE ), which give you all files on the SD card. Instead, you should use methods on Context to access package-specific directories on external storage. Your app always have access to read/write to these directories,so there is no need to permissions to request it:
Permissions can also be managed on the command-line using adb with the following commands.
Show all Android permissions:
Dumping app permission state:
Granting and revoking runtime permissions:
Installing an app with all permissions granted:
1, AM command usage
1.1, a brief introduction
The am command is an abbreviation of activity manager, which can start Service, Broadcast, kill process, monitor and other functions. These functions are very convenient to debug the program.
1.2, AM command
The command format is as follows
| command | Features | Implementation |
|---|---|---|
| am start [options] | Start Activity | startActivityAsUser |
| am startservice | Start Service | startService |
| am stopservice | Stop Service | stopService |
| am broadcast | Send broadcast | broadcastIntent |
| am restart | Restart | restart |
| am dumpheap | The heap information of the process pid is output to the file. | dumpheap |
| am send-trim-memory | Tighten the memory of the process | setProcessMemoryTrimLevel |
| am kill | Kill the specified background process | killBackgroundProcesses |
| am kill-all | Kill all background processes | killAllBackgroundProcesses |
| am force-stop | Strong kill process | forceStopPackage |
| am hang | System stuck | hang |
| am monitor | monitor | MyActivityController.run |
Let’s talk about the meaning of the [options] and parameters and how to get them correctly.
1.3、 Options
1.3.1 Starting Activity
Mainly start the Activity command am start [options] use the options parameter, then enumerate the [options] parameter of the Activity command:
1.3.2 Tightening the memory
For example: To the process with pid=12345, issue the tighten memory command level=RUNNING_LOW
The range of level is: HIDDEN, RUNNING_MODERATE, BACKGROUND, RUNNING_LOW, MODERATE, RUNNING_CRITICAL, COMPLETE
1.3.3 Other
For example: start the specified service of the user with >
1.4 Intent
There are many parameters and flags for Intent. For convenience, there are three types of parameters, common parameters, Extra parameters, and Flags parameters.
1.4.1 Common parameters
1.4.2 Extra parameters
(1). Basic type
| parameter | -e/-es | -esn | -ez | -ei | -el | -ef | -eu |
|---|---|---|---|---|---|---|---|
| Types of | String | (String) | boolean | int | long | float | uri |
The parameter es is the short name of the Extra String, example:
(2). Array type
| parameter | -esa | -eia | -ela | -efa |
|---|---|---|---|---|
| Array type | String[] | int[] | long[] | float[] |
The parameter eia is the abbreviation of Extra int array. The multiple value values are separated by commas. Example:
(3). ArrayList type
| parameter | -esal | -eial | -elal | -efal |
|---|---|---|---|---|
| List type | String | int | long | float |
The parameter efal is the short name of the Extra float Array List. The multiple value values are separated by commas. Example:
2, PM command usage
2.1, a brief introduction
The pm tool is short for package management. You can use the pm tool to perform application installation and query application information, system permissions, and control applications. The pm tool is an indispensable tool for Android development and testing. The command format is as follows:
| command | Features | Implementation |
|---|---|---|
| list packages | List app package information | PMS.getInstalledPackages |
| install [options] | Install the app | PMS.installPackageAsUser |
| uninstall [options] | Uninstall the app | IPackageInstaller.uninstall |
| Enable | enable | PMS.setEnabledSetting |
| Disable | disable | PMS.setEnabledSetting |
| hide | Hide application | PMS.setApplicationHiddenSettingAsUser |
| unhide | Display application | PMS.setApplicationHiddenSettingAsUser |
| get-install-location | Get the installation location | PMS.getInstallLocation |
| set-install-location | Set the installation location | PMS.setInstallLocation |
| path | View app path | PMS.getPackageInfo |
| clear | Clear app data | AMS.clearApplicationUserData |
| get-max-users | Maximum number of users | UserManager.getMaxSupportedUsers |
| force-dex-opt | Dex optimization | PMS.forceDexOpt |
| dump | Dump information | AM.dumpPackageStateStatic |
| Trim-caches | Tight cache target size | PMS.freeStorageAndNotify |
Principle analysis: pm command implementation is in Pm.java, and most of them are called by the corresponding method of PackageManagerService. After disbale, you can’t see the app in the desktop and application list.
2.2, detailed parameters
2.2.1 list packages
View all packages,
[options] parameters:
Disabled + enabled = total number of applications; system + third party = total number of applications.
View the 3rd party app:
View package names that have been disabled
parameter
When FILTER is not empty, only the application with the FILTER field will be output. When FILTER is empty, all applications that meet the conditions will be displayed by default.
For example, look at the package name with the weather field in the package name.
2.2.3 pm Install
[options] parameters:
parameter: Refers to the path where the apk to be installed is located
2.2.4 Other parameters
3、dumpsys
3.1 Introduction to dumpsys principle
Dumpsys is a powerful debug tool that comes with Android. It can be seen from the name. It is mainly used to dump some information of the current android system. It is a very effective means to analyze mobile phone problems, running status and usage.
Principle of implementation
The source structure of dumpsys is actually very simple, only one dumpsys.cpp
/frameworks/native/cmds/dumpsys/dumpsys.cpp
First obtain the ServiceManager object through the defaultServiceManager () function, and then find the specific service through the function checkService according to the parameters passed in the dumpsys, and execute the dump method of the service to achieve the purpose of the dump service.
3.2 dumpsy command
3.2.1 Service List
There are a lot of service lists, here are a few
| Service Name | Class name | Features |
|---|---|---|
| activity | ActivityManagerService | AMS related information |
| package | PackageManagerService | PMS related information |
| window | WindowManagerService | WMS related information |
| input | InputManagerService | IMS related information |
| power | PowerManagerService | PMS related information |
| battery | BatteryService | Battery information |
| dropbox | DropboxManagerService | |
| cpuinfo | CpuBinder | CPU |
| meminfo | MemBinder | RAM |
| dbinfo | DbBinder | database |
3.2.2 Query Service
Next, mainly talk about the dumpsys activity usage.
3.3 Activity
Options optional value
The dumpsys activity is equivalent to outputting the following seven instructions in sequence:
Cmd optional value
| cmd | Description | abbreviation |
|---|---|---|
| activities | Activity status | a |
| broadcasts | Broadcast | b |
| intents | Pending intent state | i |
| processes | process | p |
| oom | Memory overflow | o |
| services | Service status | s |
| providers | ContentProvider Status | prov |
| provider | ContentProvider status (Client side) | |
| package | Package related information | |
| all | All activities information | |
| recents | Recent activity status | |
| top | Top activity information |
Note:
cmd: The bold entry in the above table refers to the package name directly, and the services and providers can also follow the component name;
Abbreviation: Basically the first letter or the first few letters of cmd, equivalent to cmd and abbreviation: dumpsys activity broadcasts and dumpsys activity b equivalent
3.4 dumpsys meminfo
The above output can be divided into the following four parts.
PSS- Proportional Size The actual physical memory used (proportional allocation of shared memory)
Proportionally contains the memory occupied by the shared library. For example, a 9k shared library is used by 3 processes, and the size occupied by the current process is calculated as 9/3k, which is 3k.
| -sequence | Type of division | Sort | Explanation |
|---|---|---|---|
| 1 | process | PSS | Sort the display by the PSS of the process from large to small, and display one process per line; |
| 2 | OOM adj | PSS | Native/System/Persistent/Foreground/Visible/Perceptible/A Services/Home/B Services/Cached, showing the status of each class |
| 3 | category | PSS | Total PSS for various processes by Dalvik/Native/.art mmap/.dex map |
| 4 | total | — | Total memory, remaining memory, available memory, other memory |
It is also possible to output only the process information of a certain pid or package:
3.4 Usage scenarios
The following analysis uses AmberLocker as an example.
Scenario 1: Query all Service status of an App
Interpretation: The Service class name is com.amber.lockscreen.LockerHeartService, the package name is mobi.infolife.ezweather.locker.locker_2, and the baseDir (apk path) is /data/app/mobi.infolife.ezweather.locker.locker_2-2/ Base.apk, dataDir((apk data path)
runs in process pid=1115, the process name is process name mobi.infolife.ezweather.locker.locker_2, uid=10060, and the creation time and other information
Scenario 2: Query all broadcast status of an app
Scenario 3: Query all Activity status of an App
Scenario 4: Query the process status of an app
Format: ProcessRecord
There are also Services, Connections, Providers, Receivers,
Scenario 5: Query the top of the stack Activity
There are a lot of commands for dumpsys, so I won’t list them here.