As long as this blog does not indicate "transfer", it is all original, please indicate the link of this blog for reposting
Android provides a lot of command line tools, which are convenient for us to debug and view information. The following are the commands in frameworks/base/cmds (android 6.0.1).
$ tree cmds -L 1
cmds
├── am
├── appops
├── app_process
├── appwidget
├── backup
├── bmgr
├── bootanimation
├── this
├── content
├── dpm
├── hid
├── idmap
Ime── name
├── input
├── interrupter
├── media
├── pm
├── requestsync
├── screencap
├── settings
├── sm
├── svc
├── telecom
Ut── uiautomator
└── wm
Each of the above directories is a / a group of commands. The svc includes power, data, wifi, usb, nfc switches.
Here are just some of the commands I may use (am, appops, ime, input, pm, screencap, settings, svc, uiautomator, wm) to demonstrate. Let's start simple.
name
ime is related to the input method, you can use it to enable/set the input method, or you can list the existing input methods in the phone.
$ adb shell ime list -s com.sohu.inputmethod.sogou/.SogouIME com.google.android.inputmethod.pinyin/.PinyinIME com.sohu.inputmethod.sogou.xiaomi/.SogouIME
input
The input command can simulate input
For example, we want to enter 123 in the input box
adb shell input text 123
Note that to meet a few points, you must first focus on the input box, and it is best to use the native input method
We can also simulate system keys, such as the return key
adb shell input keyevent KEYCODE_BACK
We can also simulate click events, such as click x=900, y=150
$ adb shell input tap 900 150
wm
wm command to get resolution/screen density etc.
$ adb shell wm size Physical size: 1080x1920 $ adb shell wm density Physical density: 480
You can also modify the ratio of the displayed input image, but I don't know what it is, you can try this command.
$ wm overscan 10,10,100,100 $ wm overscan reset
Remember to execute reset after trying
screencap
screencap for taking screenshots
$ adb shell screencap -h usage: screencap [-hp] [-d display-id] [FILENAME] -h: this message -p: save the file as a png. -d: specify the display id to capture, default 0. If FILENAME ends with .png it will be saved as a png. If FILENAME is not given, the results will be printed to stdout.
We can save the screenshot directly to the computer
$ adb shell screencap -p | sed 's/\r$//' > screen.png
You can also save screenshots to sd card
$ adb shell 'cd sdcard; screencap -p screen.png' $ adb shell ls -l sdcard/screen.png -rw-rw---- root sdcard_rw 197116 2016-06-21 11:49 screen.png
uiautomator
uiautomator can be used for UI testing, and it can also dump the current UI structure. If you think hierarchy is not easy to use, you can also try this command. But the result is in xml form, and the information is also very complete.
$ adb shell uiautomator
Usage: uiautomator <subcommand> [options]
Available subcommands:
help: displays help message
runtest: executes UI automation tests
runtest <class spec> [options]
<class spec>: <JARS> < -c <CLASSES> | -e class <CLASSES> >
<JARS>: a list of jar files containing test classes and dependencies. If
the path is relative, it's assumed to be under /data/local/tmp. Use
absolute path if the file is elsewhere. Multiple files can be
specified, separated by space.
<CLASSES>: a list of test class names to run, separated by comma. To
a single method, use TestClass#testMethod format. The -e or -c option
may be repeated. This option is not required and if not provided then
all the tests in provided jars will be run automatically.
options:
--nohup: trap SIG_HUP, so test won't terminate even if parent process
is terminated, e.g. USB is disconnected.
-e debug [true|false]: wait for debugger to connect before starting.
-e runner [CLASS]: use specified test runner class instead. If
unspecified, framework default runner will be used.
-e <NAME> <VALUE>: other name-value pairs to be passed to test classes.
May be repeated.
-e outputFormat simple | -s: enabled less verbose JUnit style output.
dump: creates an XML dump of current UI hierarchy
dump [--verbose][file]
[--compressed]: dumps compressed layout information.
[file]: the location where the dumped XML should be stored, default is
/sdcard/window_dump.xml
events: prints out accessibility events until terminated
dump current UI structure
adb shell uiautomator dump sdcard/test.xml
settings
settings can modify/get system setting information
$ adb shell settings
usage: settings [--user NUM] get namespace key
settings [--user NUM] put namespace key value
settings [--user NUM] delete namespace key
settings [--user NUM] list namespace
'namespace' is one of {system, secure, global}, case-insensitive
If '--user NUM' is not given, the operations are performed on the owner user.
For example, we want to view android_id
$ adb shell settings get secure android_id 1dbbe170f8995d89
Check wifi status
$ adb shell settings get global wifi_on 1
Check if the date is in 24-hour format
$ adb shell settings get system time_12_24 24
svc
There is a set of commands under svc, power, data, wifi, usb, nfc, which can control its switch
E.g:
$ svc wifi
svc wifi
Control the Wi-Fi manager
usage: svc wifi [enable|disable]
Turn Wi-Fi on or off.
Control mobile network data switch
$ adb shell svc data disable $ adb shell svc data enable
appops
appops can view/modify permission related information
$ adb shell appops get com.android.phone VIBRATE: allow; time=+1d3h57m1s111ms ago; duration=+63ms READ_CONTACTS: allow; time=+2h10m59s285ms ago READ_SMS: allow; time=+2h10m49s858ms ago WRITE_SMS: allow; time=+3m46s339ms ago READ_ICC_SMS: allow; time=+2h10m49s859ms ago WRITE_CLIPBOARD: allow; time=+10d2h24m17s819ms ago WAKE_LOCK: allow; time=+5s122ms ago; duration=+14ms READ_EXTERNAL_STORAGE: allow; time=+14h31m4s898ms ago WRITE_EXTERNAL_STORAGE: allow; time=+14h31m4s898ms ago $ adb shell appops get com.android.phone READ_CONTACTS READ_CONTACTS: allow; time=+2h28m33s274ms ago
The two commands am and pm should be regarded as the most complex and most commonly used. We can start the page through am, send broadcasts, etc., we can list the apps in the phone through pm, enable and disable apps, etc. Of course, some of them require root privileges . It will not be introduced here.
The command line tools in android phones are not only these, there are also some commands in frameworks/native/cmds, such as our commonly used dumpsys , which was also introduced in my previous blog.
Knowing these tools, we can write some scripts to obtain mobile phone and app information, save the log and facilitate viewing and debugging.
Please keep the following link for reposting
My blog address