Use this command to start activity, services, send broadcast, etc. from the cmd console:C:\USERS\ADMINISTRATOR>ADB Shell AM usage:am [subcommand] [options]
Start an activity:am start [-d] [-W] <INTENT>-d:enable debugging-w: Wait for launch to complete
Start a service:am startservice <INTENT>
Send a broadcast intent:am broadcast <INTENT>
Start an INSTRUMENTATION:AM instrument [flags] <COMPONENT>-r:print RAW Results (otherwise decode report_k Ey_streamresult)-e <NAME> <value>: set argument <NAME> to <VALUE>-P <FILE> : Write profiling data to <FILE>-w:wait for instrumentation to finish before returning
Start Profiling:am profile <PROCESS> start <FILE> stop profiling:am profiles <PROCESS> stop
Start Monitoring:am Monitor [--gdb <port>]--gdb:start Gdbserv on the given port at Crash/anr
<INTENT> specifications include these flags: [-A <action>] [-D ] [-t <mime_type>] [-C < category> [-C <category>] ...] [-e|--es <EXTRA_KEY> <EXTRA_STRING_VALUE> ...] [--esn <EXTRA_KEY> ...] [--ez < Extra_key> <EXTRA_BOOLEAN_VALUE> ...] [-e|--ei <EXTRA_KEY> <EXTRA_INT_VALUE> ...] [-n <component>] [-f <flags>] [--grant-read-uri-permission] [--grant-write-uri-permission] [--debug-log-resolution] [--activity-brought-to-front] [--activity-clear-top] [--activity-clear-when-task-reset] [--activity-exclude-from-recents] [--activity-launched-from-history] [--activity-multiple-task] [--activity-no-animation] [--activity-no-history] [--activity-no-user-action] [--activity-previous-is-top] [--activity-reorder-to-front] [--activity-reset-task-if-needed] [--activity-single-top] [--receiver-registered-only] [-- Receiver-replace-pending] [<uri>] Use instance: if you start a activity: format: ADB shell am START-N package Name/package name + class name (-N class name,-a action,-d date,-m mime-type,-c category,-e extension data, etc.). Instance 1:c:\users\administrator>adb shell am start-n com.android.camera/. Camera starting:intent {cmp=com.android.camera/. CamERA} Instance 2: (with extra intent) C:\USERS\ADMINISTRATOR>ADB Shell am start-n com.android.camera/. Camera-e ThisKey thisisvalue starting:intent {cmp=com.android.camera/. Camera (has extras)} where extra's key is ABC, value is the string "Hello" can also send commands to simulate a mobile low-power environment:
Instance:
ADB shell am broadcast-a android.intent.action.BATTERY_CHANGED--ei "level" 3--ei "scale" 100
Differences in the use of ADB push and adb install in Android Dreamtale2014-03-10 23:41:44This article is submitted by Yingchun Shi (@ three vulgar little Women). Reprint please specify the original address. In the actual development of Android, the ADB command is often used, and the installation application can use ADB push or adb install. Here are the differences between the two ways of installation.
ADB push enables you to specify the installation directory. For example, after implementing "ADB push xxx.apk System/app", xxx.apk is installed in the System/app directory, the software under this directory is the system application mentioned above. (Note that the System/app is read-only, so only the root permission can be used to push the apk in, and the APK will overwrite the original APK when it is push in.) The ADB push itself means copying the file to a folder in the system, but it will register the app after the APK is push to System/app and the phone is restarted. ADB install the software installed with this command is located in the Data/app directory, with the parameter-R to force the installation, user application.
As indicated by the above two, the main differences between the ADB install and the ADB push apk are:
Push Install
Catalog System/app Data/app
Privilege system level (full access) User level (not fully open)
Remove uninstall after root uninstall
Unlimited size, Limited customization
Install PM re-registration will not be re-registered
Manually installed APK version number is the same as the system built-in API version number. A deeper layer of analysis: 1, Android system Application update mechanism
The system provides Versionname, Versioncode two properties for each application in Androidmainfest.xml.
The versionname:string type, which is used to view the version for the app's users. The Versioncode:integer type, as the basis for the system to determine whether the application can be upgraded.
2, Android system built-in application update judgment code
Code from Package update criteria for Scanpackageli functions in Frameworks/base/services/java/com/android/server/packagemanagerservice.java
From the above data analysis:
The same AP, if there is a higher version of the app under Data/app, but the older version under System, follow the old version. It is also known that if there are more than two APs in the same process but only one AP has changed the API version then the compilation error assumes two Ap:ap1 and AP2. All two APs are built after the API version update and install into the phone. And the system has built-in AP1 is the old version, the reboot will still register the old version of the AP1. At this point, the same process will appear in the system but different versions of AP1 (System/app) and AP2 (Data/app)
In summary, compilation will go wrong. Guess:
If the APS of the same process are compiled with the same version of the SDK, push into the phone, it can be run (verified). If the APS of the same process are compiled with the same version of the SDK. Install into the phone, you can run it, if you delete all the same process APS within the System/app. (verified) If the AP for the same process is compiled with the same version of the SDK, the Push/install can be (to be verified).
Author: Yingchun Shi, female programmer, mainly research on the framework layer of Android system, currently serving on HTC.
Original link: http://www.grackertalk.com/?p=48
Usage of ADB shell am
