Install adb from android studio

Platform-tools: r31.0.3
ADB: 1.0.41 (31.0.3-7562133)
Fastboot: 31.0.3-7562133
Make_f2fs: 1.14.0 (2020-08-24)
Mke2fs: 1.46.2 (28-Feb-2021)
Последнее обновление утилит в шапке: 01.08.2021

ADB (Android Debug Bridge — Отладочный мост Android) — инструмент, который устанавливается вместе с Android-SDK и позволяет управлять устройством на базе ОС Android.
Работает на всех Android-устройствах, где данный функционал не был намеренно заблокирован производителем.
Здесь и далее: PC — ПК, компьютер к которому подключено устройство.
ADB — консольное приложение для PC, с помощью которого производится отладка Android устройств, в том числе и эмуляторов.
Работает по принципу клиент-сервер. При первом запуске ADB с любой командой создается сервер в виде системной службы (демона), которая будет прослушивать все команды, посылаемые на порт 5037.
Официальная страница
ADB позволяет:

Посмотреть какие устройства подключены и могут работать с ADB.
Просматривать логи.
Копировать файлы с/на аппарат.
Устанавливать/Удалять приложения.
Удалять (очищать) раздел data.
Прошивать (перезаписывать) раздел data.
Осуществлять различные скрипты управления.
Управлять некоторыми сетевыми параметрами.

Поставляется ADB в составе инструментария разработчика Андроид (Android SDK), который, в свою очередь входит в состав Android Studio.

Если что-то неправильно, то в списке подключенных устройств (List of devices attached) будет пусто.

Скрытые команды ADB
adb -d Команда посылается только на устройство подключенное через USB.
Внимание: Выдаст ошибку, если подключено больше одного устройства.

adb -e Команда посылается на устройство в эмуляторе.
Внимание: Выдаст ошибку, если подключено больше одного эмулятора.

adb -s Команда посылается на устройство с указанным серийным номером:

adb -p Команда посылается на устройство с указанным именем:
Если ключ -p не указан, используется значение переменной ANDROID_PRODUCT_OUT.

adb devices Список всех подсоединенных устройств.

adb connect [: ] Подсоединиться к андроид хосту по протококу TCP/IP через порт 5555 (по умолчанию, если не задан).

adb disconnect [ [: ]] Отсоединиться от андроид подключенного через TCP/IP порт 5555 (по умолчанию, если не задан).
Если не задан ни один параметр, отключиться от всех активных соединений.

adb push Копировать файл/папку PC->девайс.

adb pull [ ] Копировать файл/папку девайс->PC.

adb sync [ ] Копировать PC->девайс только новые файлы.
Ключи:
-l Не копировать, только создать список.

adb shell Запуск упрощенного unix shell.
Примеры использования

adb emu Послать команду в консоль эмулятора

adb install [-l] [-r] [-s] Послать приложение на устройство и установить его.
Пример: adb install c:/adb/app/autostarts.apk Установить файл autostarts.apk лежащий в папке /adb/app/ на диске с:
Ключи:
-l Блокировка приложения
-r Переустановить приложение, с сохранением данных
-s Установить приложение на карту памяти
Установка split apk

adb uninstall [-k] Удаление приложения с устройства.
Ключи:
-k Не удалять сохраненные данные приложения и пользователя.

adb wait-for-device Ждать подключения устройства.

adb start-server Запустить службу/демон.

adb kill-server Остановить службу/демон.

adb get-state Получить статус:
offline Выключен.
bootloader В режиме начальной загрузки.
device В режиме работы.

adb get-serialno Получить серийный номер.

adb status-window Непрерывный опрос состояния.

adb remount Перемонтировать для записи. Требуется для работы скриптов, которые изменяют данные на.

adb reboot bootloader Перезагрузка в режим bootloader.

adb reboot recovery Перезагрузка в режим recovery.

adb root Перезапуск демона с правами root

adb usb Перезапуск демона, прослушивающего USB.

adb tcpip Перезапуск демона, прослушивающего порт TCP.

adb ppp [параметры] Запуск службы через USB.
Note: you should not automatically start a PPP connection. refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
Параметры:
defaultroute debug dump local notty usepeerdns

FastBoot — консольное приложение для PC. Используется для действий над разделами

fastboot devices Список присоединенных устройств в режиме fastboot.
fastboot flash Прошивает файл .img в раздел устройства.

fastboot erase Стереть раздел.
Разделы: boot, recovery, system, userdata, radio
Пример: fastboot erase userdata Стирание пользовательских данных.

fastboot update Прошивка из файла имя_файла.zip

fastboot flashall Прошивка boot + recovery + system.

fastboot getvar Показать переменные bootloader.
Пример: fastboot getvar version-bootloader Получить версию bootloader.

fastboot boot [ ] Скачать и загрузить kernel.

fastboot flash:raw boot [ ] Создать bootimage и прошить его.

fastboot devices Показать список подключенных устройств.

fastboot continue Продолжить с автозагрузкой.

fastboot reboot Перезагрузить аппарат.

f astboot reboot-bootloader Перезагрузить девайсв режим bootloader.
Перед командами fastboot можно использовать ключи:
-w стереть данные пользователя и кэш
-s Указать серийный номер устройства.
-p

Указать название устройства.
-c Переопределить kernel commandline.
-i Указать вручную USB vendor id.
-b Указать в ручную базовый адрес kernel.
-n

Указать размер страниц nand. по умолчанию 2048.

Команду logcat можно использовать с машины разработки
$ adb logcat
или из удаленного shell
# logcat Каждое сообщение лога в Android имеет тэг и приоритет
Тэг – это строка указывающая компонент системы, от которого принято сообщение (например: View для системы view)
Приоритет – имеет одно из нижеследующих значений (в порядке от меньшего к большему):
V — Verbose (Низший приоритет).
D — Debug
I — Info
W — Warning
E — Error
F — Fatal
S — Silent (Наивысший приоритет, при котором ничего не выводится).

Получить список тэгов, используемых в системе, вместе с их приоритетами можно запустив logcat. В первых двух столбцах каждого из выведенных сообщений будут указаны / .
Пример выводимого logcat сообщения:
I/ActivityManager( 585): Starting activity: Intent

Для уменьшения вывода лога до приемлемого уровня нужно использовать выражения фильтра. Выражения фильтра позволяют указать системе нужные комбинации и , остальные сообщения система не выводит.
Выражения фильтра имеют следующий формат : . где указывает нужный тэг, указывает минимальный уровень приоритета для выбранного тэга. Сообщения с выбранным тэгом и приоритетом на уровне или выше указанного записываются в лог. Можно использовать любое количество пар : в одном выражении фильтра. Для разделения пар : используется пробел.

Пример ниже выводит в лог все сообщения с тэгом «ActivityManager» с приоритетом «Info» или выше, и сообщения с тэгом «MyApp» и приоритетом «Debug» или выше:
adb logcat ActivityManager:I MyApp:D *:S
Последний элемент в выражении фильтра *:S устанавливает приоритет «silent» для всех остальных тэгов, тем самым обеспечивая вывод сообщений только для «View» и «MyApp». Использование *:S – это отличный способ для вывода в лог только явно указанных фильтров (т.е. в выражении фильтра указывается «белый список» сообщений, а *:S отправляет все остальное в «черный список»).

При помощи следующего выражения фильтра отображаются все сообщения с приоритетом «warning» или выше для всех тэгов:
adb logcat *:W

Если logcat запускается на машине разработчика (не через удаленный adb shell), можно также установить значение выражения фильтра по умолчанию задав переменную окружения ANDROID_LOG_TAGS:
export ANDROID_LOG_TAGS=»ActivityManager:I MyApp:D *:S»

Следует обратить внимание что задав переменную окружения ANDROID_LOG_TAGS она не будет работать в эмуляторе/устройстве, если вы будете использовать logcat в удаленном shell или используя adb shell logcat.
Вышеописанная команда export работает в ОС *nix и не работает в Windows.

Контроль формата вывода лога

Сообщения лога в дополнение к тэгу и приоритету содержат несколько полей метаданных. Можно изменять формат вывода сообщений показывая только конкретные поля метаданных. Для этого используется параметр -v и указывается один из ниже перечисленных форматов вывода.

brief Показывать приоритет/тэг и PID процесса (формат по умолчанию).
process Показывать только PID.
tag Показывать только приоритет/тэг.
thread Показывать только процесс:поток и приоритет/тэг.
raw Показать необработанное сообщение, без полей метаданных.
time Показывать дату, время вызова, приоритет/тэг и PID процесса.
long Показывать все поля метаданных и отдельно сообщения с пустыми строками.

При запуске logcat можно указать формат вывода используя параметр -v:
adb logcat [-v

Источник

Help, adb is not found!

So you’ve downloaded Android Studio and installed the SDK. Eventually you may come across a tutorial telling you to type adb , maybe to enable debug mode in Firebase. That’s when it happens:

If your first instinct is to search for “how to install adb,” you’ll likely end up with some instructions about installing it in via your operating system’s package manager or downloading random zip files from phone customization websites. But this isn’t necessary! adb ships with the Android SDK installed by Android Studio, and with a couple of manual steps you can ensure that you’re always using the same up to date tools that your IDE is!

What’s the deal with adb?

adb stands for the “Android Debug Bridge,” which is a command line utility that is the debug multitool for Android. Typically it’s installed via Android Studio when you install the Android SDK under platform-tools , but it takes some amount of setup for your operating system to know to look there.

Читайте также: Три вряд для андроид

First open up Android Studio and navigate to “Tools > SDK Manager” from the menu.

Towards the top of the window, you can see the path where the IDE installed the Android SDK.

Now open up your terminal, type cd and paste in this path. This will work on Windows, MacOS, and Linux, but on Windows you may need to press shift+insert to paste into a terminal:

Next type cd platform-tools :

Then type ls (or dir on Windows). You should see adb or adb.exe depending on your operating system. From here you can type ./adb and see some program output.

You can run adb now, but I’ve never found a tutorial that starts with “copy your SDK path, cd into platform-tools, and type ./ before adb .” To get the experience many Android devs enjoy, you must update your PATH environment variable. This will be different on each operating system, and I’ll list out MacOS and Windows below. On Linux the steps can vary, but the MacOS instructions will work in some cases.

MacOS Configuration

MacOS (and Linux) users will typically use zsh or bash for their shell. To temporarily add the platform-tools directory to your PATH , type:

So in my example above, this becomes:

Now, whenever you type adb in this terminal window you can execute adb commands. But how do you get this to stick?

Since Android Studio tends to install the Android SDK in your user directory, you’ll want to edit the PATH for your user. And since it’s a command line utility, you’ll only need to update it for your terminal (as opposed to Mac GUI applications). To do this, you’ll want to edit the .profile file in your home directory (if this doesn’t exist, .bash_rc will achieve a similar result). This file will be hidden by default, so you may not see it Finder. Open this file in your favorite text editor:

and add this to the bottom:

Which, on my machine becomes:

Adding the extra define for ANDROID_SDK_ROOT is unnecessary, but it may help with some more complicated power user tools as well, such as the Cocos 2D command line utility.

With that, open a new terminal window and type adb . If you’ve done everything right, you’ll get a help page listing adb ‘s usage.

Windows Configuration

Windows is slightly different, and I’ll work entirely in Power Shell. Just like before, I can use the SDK manager to find my install location:

Источник

ADB Android Install Guide: Drivers and Commands

In this article, we will explore how you can use the ADB to gain some fine-grained control when you’re installing, testing, diagnosing, and managing one or more devices and emulators.

For my first few years as a software developer, primarily working with the Android SDK, I had no idea of what the Android Debug Bridge (ADB/adb) was, what it did, or when to use it.

Amusingly, it was not some professional goal which motivated me to learn about it initially. Rather it was my boot looping Nexus 6 which I desperately wanted to resurrect. For a problem like that, Android Studio and Gradle are about as useful as a waterproof tea bag.

I would also like to mention that this article has been written with two kinds of individuals in mind:

Those who are familiar with CLI, Shell, Processes, and the Client-Server Model
Those who are not familiar with CLI, Shell, Processes, and the Client-Server Model

For those in the first category, you may wish to skip the section titled: «How to Work With The ADB.»

For those in the second category, I will assume you were like me as a Junior developer and know very little about CLIs, Shells, and the ADB. The first section is a soft introduction and glossary for some basic terms and ideas, explained in the simplest way I can manage.

Preliminaries

Here, we will learn about some topics which are important if you want to understand how the ADB works and is used.

Some of you may have been scared away from learning command line tools in the past by sneering Vim enthusiasts or judgmental Unix System Administrators. As you will see, I freely admit that CLI is not ideal for how my brain works, so I think you might enjoy my take on the subject.

Command Line

Simply put, a command line is an interface (way of sending/receiving information) to a computer which only uses lines of text.

It is important to understand that a command line interface (CLI) is not itself a program, but rather some programs will provide a CLI (and perhaps other interfaces such as a GUI as well).

At some point, you may have typed something into Windows Command Prompt (or MS-DOS if you are a 90s kid like me), Mac Terminal, or something like GNOME Terminal common on many Linux distributions. All of these are primarily used via a CLI.

The benefits and deficits of using a CLI depend largely on the individual using it, and what kind of problem they are trying to solve. I personally do not like using a CLI unless it is for something that I do almost every day.

My brain is simply not suited for memorizing obscure shorthand text commands (I had trouble learning to read as a kid for the same reason), so I must rely on a great deal of repetition-based implicit memory (muscle memory) and cheat sheets.

For those who are willing to put the time in even if it is a struggle (like I do), or those who are really quite good at remembering such things, you will likely learn to appreciate how much more efficient you can be within a CLI versus a GUI.

Many operations can be carried out in a fraction of the time it takes to point and click your way through various menus and screens. It is also possible to write scripts, which are files containing a series of text commands, that can increase your efficiency even further.

How to use the ABD Shell

I will have to assume that you are familiar with the term Operating System (OS), which includes Android, iOS, Windows, Mac, Linux, and any other Unix-like system.

Why is this term relevant to the ADB? To give an explanation which prioritizes clarity over precision, the Android OS is based on Linux, and Linux is based on Unix.

As a result of this, we can use the ADB to get a hold of the Unix Shell for the device or emulator we are working with. This allows us a great deal of flexibility, capabilities, and control over the device or emulator by directly interacting with its shell.

A shell is a general term for the program which you use to interact with an OS. Just as a turtle shell provides protection and access to a turtle (and is the outermost layer), the shell of an OS both protects and provides access to the inner workings of the OS. Personally, I was quite surprised to learn that «Shell» was not some esoteric acronym.

Do not feel the need to overthink this term. If you are reading this on a computer of some kind, you used a shell to help you get here.

A shell can provide either or both a CLI or GUI. In either case you will use it to create/update/delete/move files, start other programs, and access the various services of the OS which are made available through the shell.

How to use the ABD Client and ABD Server

Again, let us start with a slightly imprecise explanation which is hopefully easier to understand. I will correct this definition shortly, though.

Clients and Servers are both computers. The reason why we differentiate them in this way is based on their role. For example, your computer (whether it is a desktop, laptop, phone, or whatever else) is a Client of a freeCodeCamp Server, which serves you this HTML page.

In general, a client is something which uses something else, whereas a server is that which is being used. Do not overthink this term, as a Client-Server Model can describe a very large number of things both inside and outside of computing.

Now, when I said that Clients and Servers are both “computers”, that is not really true in the context that we will use these terms later on.

Читайте также: Philips android tv iptv

As programmers and engineers, we typically ought to think of Clients and Servers as being processes (a process is simply a running program).

This means that while a Client process and a Server process often do run on separate computers, it is also fine if they run on the same computer.

They will occupy distinct locations in the memory space of said computer, so effectively the only difference is that they will communicate using IPC (inter-process communication) as opposed to sending messages to each other through a network connection.

As we will see shortly, the ADB makes use of a Server process, which allows multiple developers (multiple clients) to manage multiple Android devices and/or emulators.

In an enterprise setting, this Server process would likely sit on a remote (communicated to through a network connection) computer, but we will set up a Server which is local to our Client. Doing that will be much simpler than you probably think it will be.

What is an ABD Daemon?

In case you skipped ahead, I already explained that a process is simply a running program. A Daemon is a process which runs in the background, which is to say that the user does not directly interact with it.

For example, if you open a web browser, then chances are that the actual work of managing the network connections required to connect to the Internet will be carried out by something like a NetworkManager Daemon (as opposed to the browser process itself).

Each Android device (physical or emulated), assuming it is configured properly, will have an ADB Daemon (adbd) which executes commands given to it by a Server process.

In short, when our Client issues a command to the Server, the Server will forward that command to the ADBD, which will execute it on the device.

How to Use ADB for Android Development

For the remainder of this article, we will explore the following topics:

Drivers and configuration necessary to use the ADB on your system
Using the ADB with physical devices and emulators
Basic commands using the ADB’s CLI
A glance at more complicated usage using an Android device’s Shell via the ADB

Before proceeding, you will want to establish what CLI tool you will be using to interact with the ADB. On Windows, I prefer using PowerShell, but Command Prompt would work too. For Linux and Mac, the default Terminal should work.

Feel free to use whatever gets the job done.

This article contains a very detailed explanation of the whole process, but I have prepared a video tutorial which covers it succintly here:

Video tutorial for the adb.

How To Understand The CLI Examples

This article contains many commands to be inputted to your preferred CLI tool. Any part of a given command which changes situationally will be written within angle brackets.

Do not include the angle brackets in the CLI command you write.

For example, if I wrote.

. you would substitute the angle brackets and name for the actual value, such as:

adb pair 192.168.0.1:5554

ABD Drivers & Configuration

Firstly, ensure that you have the latest (or at least a recent) version of the Android SDK Platform-Tools. If for some reason you do not use Android Studio (AS), click that link and download the standalone package for your respective OS.

If you have Android Studio, you can download or update this package using the SDK Manager.

There is typically a toolbar icon in AS to open the SDK Manager, but they like to change what it looks like practically every hotfix.

If you do not have luck finding it, go to File -> Settings and in the search bar, type “SDK”, and search for the “Android SDK” menu item.

Systems setting showing that Android SDK Platform Tools are installed

The next step changes depending on a number of variables. As discussed in the Preliminaries section, the ADB uses a Client-Server Model which allows a lot of flexibility in how you use the tool.

To be more specific, you may have:

Multiple Clients interacting with a remote Server
A Server which is local (same computer) to one Client
A variety of physical devices and emulators hooked up to the same server

Advanced configuration with multiple Clients and an exceedingly large number of devices is possible with the ADB, but outside of the scope of this article.

One Server can manage up to 16 emulators and as many physical devices as you would like (within reason), without requiring advanced configuration.

For the remainder of this article, the most we will work with is one physical device and one emulator for a single ADB server process.

How to Configure An ABD Emulator

Most likely you do not need to make any further configurations, but it is possible you may need to enable Developer Options on your emulator. You will know very shortly if it is working properly when we get to our first few ADB commands.

If you do wish to enable this feature on your emulator, you will need to research how to do that for your particular version of Android.

USB Debugging – How to Configure a Physical Device

If you are not planning to use a physical Android device, you can skip this section. However, it is worth noting that you may still need to enable Developer Options

In order to proceed, you will need to configure either USB Debugging or WiFi Debugging on your Android device and development machine.

In either case, start by enabling Developer Options on your device. You will need to research how to do that for your particular version of Android.

USB Debugging

Ensure that you have enabled USB Debugging on the Android device via Developer Options. The link I shared above will describe that process, which tends to change somewhat across different versions of the Android OS.

Before proceeding, Windows users will need to download a USB Driver. Ubuntu users also require some extra steps. For Mac and Chrome OS, you should be good to go.

Once USB Debugging is enabled via Developer Options, connect your Android device via a USB cable.

WiFi Debugging

If you happen to have multiple physical devices or a shortage of USB cables, then you may want to opt for WiFi Debugging.

Again, visit Developer Options on your Android device and enable Wireless debugging. It should prompt you about Allowing debugging on the network which the device is currently connected to, which you should allow (assuming that is the appropriate network).

Time to start working with your CLI. First, you will need to locate the platform-tools directory (or folder – same thing) within your Android SDK installation directory.

Assuming you have Android Studio installed, a quick way to locate it via the app is to again go to File -> Settings, then type “SDK” in the search bar. The “Android SDK” menu will show you where your SDK is installed, which will be the directory that should contain platform-tools.

In the example below, I copied the path to my Android SDK directory, and then opened an instance of Windows PowerShell. I then typed the following commands:

Change Directory:

List Files and Directories:

Next, I typed cd platform-tools to navigate to that directory. Note that the following steps assume you are using a device which is running Android OS 11 or higher.

If you are working with a device running Android 10 or lower, detailed instructions for that situation can be found here.

Once you are within the platform-tools directory, you are ready to pair an Android device to a development machine using the following steps:

1. Within the Wireless debugging submenu in Settings -> System -> Developer options, select Pair device with pairing code.

2. Within your CLI tool which should be set to the platform-tools directory, enter the following command:

where both the IP address and the Port come from the dialogue on your Android device which popped up after selecting Pair device with pairing code (do not include the angle brackets).

Note: You may need to prepend your call to adb with some other symbols or commands depending on which CLI tool you are using, your OS, and your access controls. For example, I had to type .\adb pair :

using PowerShell on Windows.

3. Assuming things went well with your CLI, you will be prompted to enter the pairing code which was made visible in the same dialog on the Android device which gave you the IP address and Port number.

4. After entering the pairing code, you will know this operation was successful if you receive a message stating:

Successfully paired to :

5. If you are using Windows or Linux, you will also need to run the following command using the IP Address & Port which is visible from within the Wireless debugging preferences menu (not the dialogue which pops up after selecting Pair device with pairing code):

after which you should receive a notification on the phone to indicate that you are connected.

How to Use The ADB: Commands

Assuming you managed to properly configure your Android device and your development machine, you can now use the ADB tool.

Before proceeding, navigate to the directory which contains adb using a CLI tool (unless you just followed the steps in the previous section for setting up WiFi debugging).

Otherwise do so now, or check out that section for instructions on how to locate that folder.

How to See Which Devices Are Currently Connected To The Server

You can now start up an adb server by calling just about any command on the ADB except adb kill-server . Whether or not your server process is running, type in the following command:

In the above screenshot, I first called adb devices when my Android phone was connected to the server. After killing the server via the adb kill-server command, I once again called devices which restarted the server.

Again, if an ADB server is not currently running, calling more or less any ADB command will start the server back up (except adb kill-server , of course). There is an explicit adb start-server command, but in practice I have never needed to use it.

Since the server was reset, devices did not return any items. Therefore, before moving to the next example I had to once again use the adb pair and adb connect (if on Windows or Linux) commands described in the previous section.

I have now fired up an emulator using PowerShell and the emulator program which is also located in a subdirectory of platform-tools called «emulator.»

You may of course use the AVD Manager or Android Studio to start up an emulator to follow along with the example if you would like to.

If you have many connected devices, a useful option for the adb devices command is -l , which gives you more information about the devices.

Below you will see several entries which refer to my physical Android device, as well as an emulator which has been attached to a specific port:

How to Send Commands To A Specific Device

To avoid accidentally bricking my phone, I want to send commands to the emulator instead. To do this, I must prepend the -s option, followed by the serial number of the target device, before typing the command.

The serial number is the first set of characters which describes a connected device after using the devices command.

For example, the emulator’s serial number in this case is just the word emulator followed by the port which the emulator is currently attached to.

The other red arrow points to the serial number for my phone (blocked out for obvious reasons).

Naturally, if you only have one device connected (whatever kind it is), you do not need to use the -s option.

Install An APK (App) On A Device

I am now going to install a test APK on the running emulator using the adb install command.

This is basically equivalent to having Android Studio and Gradle install a debug APK. As you will see, test APKs require the -t option after the install command:

adb -s install -t

Note: The Android OS requires that any APK must be signed before it can be installed (even if it is just a test/debug APK).

One solution is to build and run the app to be installed in Android Studio, which will sign it with a generated debug certificate. There are several other ways to sign such an APK which you can explore by visiting this link.

What Else Can ADB Do?

Before we take a look at some more advanced usage of the ADB, I strongly encourage you to try the adb —help command. As is customary for most CLI based programs, the help command will print out documentation which describes the various commands and options of the tool.

I am happy to say that the documentation for the ADB is quite legible and useful, which is not always the case in CLI programs.

Advanced ADB Usage Tips

It would be a waste of time for both of us to cover every usage and command of the ADB in this article.

In case there is any confusion, using the ADB to install APKs and do many of the things which Android Studio and Gradle do for you is not something that I would recommend (unless you have a good reason to do so).

With that being said, there are plenty of things that the ADB can do which are either difficult or impossible to do without it.

In the preliminaries section, I mentioned that the ADB can be used to get a hook to the shell of the device. To finish this article off, we will look at how to use shell commands and where to find more information about them.

If you do not know what a shell is, you probably skipped the section above where I explained that.

How to Use the ABD Shell

Sending a command to the device’s shell using the ADB is fairly simple. Remember that if you have multiple devices connected, follow it with -s to direct the command to a specific device.

To make a single shell command, we must use the adb shell command (big surprise, eh?), followed by the actual command we want to make on the device’s shell:

As mentioned previously, the ls command displays a list of files and directories at the CLI’s current directory. This happens to be the Android device’s root directory until we move to a different one.

If you plan to be making many commands via the Shell, you can also start an interactive Shell session. This can be done via the simple command:

While in an interactive Shell session, you can type Shell commands directly without further use of adb shell .

Note that when you want to quit the interactive Shell session, you can do so by typing exit or hitting Ctrl + D.

There are a variety of different commands and utilities you can work with via the Shell. The ActivityManager ( am ) of an Android device can be particularly useful for testing different components (Activities, Services, BroadcastReceivers, to name a few) of an Android app under different circumstances.

Suppose we want to launch straight into a particular Activity, but this Activity is not designated as the launcher Activity in the manifest.

After that you can use the following command to go straight to it:

Install adb from android studio