Android Debug Bridge (adb)

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Android Debug Bridge (adb) to uniwersalne narzędzie wiersza poleceń, które umożliwia komunikację z urządzeniem. Polecenie adb ułatwia wykonywanie różnych czynności na urządzeniach, takich jak instalowanie i debugowanie aplikacji. adb zapewnia dostęp do powłoki Unix, której można używać do uruchamiania różnych poleceń na urządzeniu. Jest to program klient-serwer, który składa się z 3 elementów:

• Klient, który wysyła polecenia. Klient działa na komputerze, na którym tworzysz aplikacje. Aby wywołać klienta z terminala wiersza poleceń, uruchom polecenie adb.
• Demon (adbd), który uruchamia polecenia na urządzeniu. Demon działa jako proces w tle na każdym urządzeniu.
• Serwer zarządzający komunikacją między klientem a demonem. Serwer działa jako proces w tle na maszynie, której używasz do programowania.

adb wchodzi w skład pakietu narzędzi platformy Android SDK. Pobierz ten pakiet za pomocą Menedżera SDK, który instaluje go na stronie android_sdk/platform-tools/. Jeśli potrzebujesz samodzielnego pakietu narzędzi platformy SDK do Androida SDK, pobierz go tutaj.

Informacje o podłączaniu urządzenia do używania przez adb, w tym o używaniu Asystenta połączenia do rozwiązywania typowych problemów, znajdziesz w artykule Uruchamianie aplikacji na urządzeniu.

Jak działa narzędzie adb

Gdy uruchamiasz klienta adb, najpierw sprawdza on, czy trwa już proces serwera adb. Jeśli go nie ma, rozpocznie się proces serwera. Po uruchomieniu serwer tworzy powiązanie z lokalnym portem TCP 5037 i nasłuchuje poleceń wysyłanych z klientów adb.

Uwaga: wszystkie klienty adb używają portu 5037 do komunikacji z serwerem adb.

Serwer konfiguruje połączenia ze wszystkimi uruchomionymi urządzeniami. Lokalizuje emulatory, skanując porty o nieparzystych numerach w zakresie od 5555 do 5585, czyli do zakresu używanego przez pierwszych 16 emulatorów. Gdy serwer znajdzie demona adb (adbd), skonfiguruje połączenie z tym portem.

Każdy emulator używa pary sekwencyjnych portów – portu parzystego do obsługi połączeń z konsolą i portu nieparzystego dla połączeń adb. Przykład:

Emulator 1, konsola: 5554
Emulator 1, adb: 5555
Emulator 2, konsola: 5556
Emulator 2, adb: 5557
i tak dalej.

Jak widać, emulator podłączony do adb przez port 5555 jest taki sam jak emulator, którego konsola nasłuchuje na porcie 5554.

Gdy serwer skonfiguruje połączenia ze wszystkimi urządzeniami, możesz uzyskać dostęp do nich za pomocą poleceń adb. Serwer zarządza połączeniami z urządzeniami i obsługuje polecenia z wielu klientów adb, więc możesz sterować każdym urządzeniem z poziomu dowolnego klienta lub za pomocą skryptu.

Włącz debugowanie adb na urządzeniu

Aby używać narzędzia adb na urządzeniu podłączonym przez USB, musisz włączyć Debugowanie USB w ustawieniach systemu urządzenia w sekcji Opcje programisty. W Androidzie 4.2 (poziom interfejsu API 17) i nowszych ekran Opcje programisty jest domyślnie ukryty. Aby był widoczny, włącz Opcje programisty.

Możesz teraz połączyć urządzenie przez USB. Aby sprawdzić, czy urządzenie jest połączone, uruchom polecenie adb devices z katalogu android_sdk/platform-tools/. Jeśli urządzenie jest połączone, jego nazwa będzie widoczna jako „urządzenie”.

Uwaga: po podłączeniu urządzenia z Androidem 4.2.2 (poziom interfejsu API 17) lub nowszym system wyświetli okno z pytaniem, czy zaakceptować klucz RSA umożliwiający debugowanie na tym komputerze. Chroni on urządzenia użytkowników, ponieważ sprawia, że debugowanie USB i inne polecenia adb nie mogą być wykonywane, dopóki nie odblokujesz urządzenia i nie potwierdzisz, że widzisz to okno.

Więcej informacji o łączeniu się z urządzeniem przez USB znajdziesz w artykule Uruchamianie aplikacji na urządzeniu sprzętowym.

Połącz się z urządzeniem przez Wi-Fi

Uwaga: instrukcje poniżej nie dotyczą urządzeń Wear z Androidem 11 (poziom API 30). Więcej informacji znajdziesz w przewodniku debugowania aplikacji na Wear OS.

Obsługa bezprzewodowego wdrażania i debugowania aplikacji na stacji roboczej za pomocą Androida 11 (poziom interfejsu API 30) i nowszych przy użyciu Android Debug Bridge (adb). Aplikację z możliwością debugowania możesz na przykład wdrożyć na wielu urządzeniach zdalnych bez konieczności fizycznego podłączania urządzenia przez USB. Dzięki temu nie trzeba rozwiązywać typowych problemów z połączeniem USB, takich jak instalacja sterowników.

Zanim zaczniesz korzystać z debugowania bezprzewodowego, wykonaj te czynności:

• Upewnij się, że Twoja stacja robocza i urządzenie są połączone z tą samą siecią bezprzewodową.

• Sprawdź, czy na telefonie działa Android 11 (poziom interfejsu API 30) lub nowszy w przypadku telefonu. W przypadku telewizora i Wear OS urządzenie musi mieć Androida w wersji 13 (poziom interfejsu API 33) lub nowszego. Więcej informacji znajdziesz w artykule Sprawdzanie i aktualizowanie wersji Androida.

• Jeśli używasz IDE, upewnij się, że masz zainstalowaną najnowszą wersję Android Studio. Możesz go pobrać stąd.

• Na swojej stacji roboczej zaktualizuj narzędzia platformy SDK do najnowszej wersji.

Aby korzystać z debugowania bezprzewodowego, musisz sparować urządzenie ze stacją roboczą za pomocą kodu QR lub kodu parowania. Stacja robocza i urządzenie muszą być połączone z tą samą siecią bezprzewodową. Aby połączyć się z urządzeniem, wykonaj te czynności:

1. Włącz opcje programisty na urządzeniu.

2. Otwórz Android Studio i z menu konfiguracji uruchamiania wybierz Paruj urządzenia przez Wi-Fi.

   

   Rysunek 1. Menu uruchamiania konfiguracji.

   Pojawi się okno Paruj urządzenia przez Wi-Fi, tak jak na ilustracji 2.

   

   Rysunek 2. Wyskakujące okienko, w którym możesz sparować urządzenia przy użyciu kodu QR lub kodu parowania.

3. Na urządzeniu kliknij Debugowanie bezprzewodowe i sparuj urządzenie:

   

   Rysunek 3. Zrzut ekranu pokazujący ustawienie Debugowanie bezprzewodowe na telefonie Google Pixel.

   1. Aby sparować urządzenie przy użyciu kodu QR, wybierz Sparuj urządzenie z kodem QR i zeskanuj kod QR otrzymany w wyskakującym okienku Parowanie urządzeń przez Wi-Fi pokazanym na ilustracji 2.

   2. Aby sparować urządzenie przy użyciu kodu parowania, w wyskakującym okienku Sparuj urządzenia przez Wi-Fi wybierz Sparuj urządzenie za pomocą kodu parowania. Na urządzeniu wybierz Sparuj przy użyciu kodu parowania i zanotuj podany 6-cyfrowy kod. Gdy urządzenie pojawi się w oknie Paruj urządzenia przez Wi-Fi, kliknij Sparuj i wpisz 6-cyfrowy kod wyświetlony na urządzeniu.

      

      Rysunek 4. Przykład wpisania 6-cyfrowego kodu.

4. Po sparowaniu urządzenia możesz spróbować wdrożyć na nim aplikację.

   Aby sparować inne urządzenie lub zapomnieć obecne urządzenie na stacji roboczej, otwórz na urządzeniu Debugowanie bezprzewodowe. W sekcji Sparowane urządzenia kliknij nazwę stacji roboczej i wybierz Zapomnij.

5. Jeśli chcesz szybko włączyć lub wyłączyć debugowanie bezprzewodowe, możesz użyć kafelków Szybkich ustawień dla programistów dotyczących Debugowania bezprzewodowego, które znajdziesz w sekcji Opcje programisty > Kafelki dla programistów szybkich ustawień.

   

   Rysunek 5. Ustawienie Kafelki szybkich ustawień dla programistów umożliwia szybkie włączanie i wyłączanie debugowania bezprzewodowego.

Połączenie Wi-Fi za pomocą wiersza poleceń

Jeśli chcesz połączyć się z urządzeniem za pomocą wiersza poleceń bez Android Studio, wykonaj te czynności:

1. Włącz na urządzeniu opcje programisty w sposób opisany wcześniej.

2. Włącz na urządzeniu Debugowanie bezprzewodowe w sposób opisany wcześniej.

3. Na swojej stacji roboczej otwórz okno terminala i przejdź do: android_sdk/platform-tools.

4. Aby znaleźć swój adres IP, numer portu i kod parowania, wybierz Sparuj urządzenie z kodem parowania. Zwróć uwagę na adres IP, numer portu i kod parowania wyświetlony na urządzeniu.

5. Na terminalu stacji roboczej uruchom adb pair ipaddr:port. Użyj powyższego adresu IP i numeru portu.

6. Gdy pojawi się prośba, wpisz kod parowania, jak pokazano poniżej.

   

   Rysunek 6. Pojawi się komunikat, że urządzenie zostało sparowane.

Rozwiązywanie problemów z połączeniem bezprzewodowym

Jeśli masz problemy z bezprzewodowym połączeniem urządzenia z urządzeniem, wykonaj te czynności, aby je rozwiązać.

Sprawdź, czy Twoja stacja robocza i urządzenie spełniają wymagania wstępne

Sprawdź, czy stacja robocza i urządzenie spełniają wymagania wstępne wymienione na początku tej sekcji.

Sprawdź, czy nie wystąpiły inne znane problemy

Poniżej znajdziesz listę aktualnych znanych problemów z debugowaniem bezprzewodowym (w programie adb lub Android Studio) i sposobów ich rozwiązania:

• Wi-Fi nie łączy się: bezpieczne sieci Wi-Fi (np. firmowe sieci Wi-Fi) mogą blokować połączenia P2p i uniemożliwiać łączenie się przez Wi-Fi. Spróbuj połączyć się za pomocą kabla lub innej (niefirmowej) sieci Wi-Fi. Kolejną opcją jest połączenie bezprzewodowe przez adb connect ip:port przez tcp/ip (po pierwszym połączeniu USB), na wypadek gdyby można było skorzystać z sieci innej niż firmowa.

• adb przez Wi-Fi czasami wyłącza się automatycznie: może się to zdarzyć, gdy urządzenie przełączy się na inną sieć Wi-Fi lub rozłączy się z siecią. Aby rozwiązać ten problem, połącz się ponownie z siecią.

• Urządzenie nie łączy się po sparowaniu: adb używa mDNS do wykrywania sparowanych urządzeń i automatycznego łączenia się z nimi. Jeśli konfiguracja Twojej sieci lub urządzenia nie obsługuje mDNS albo ta funkcja została wyłączona, musisz ręcznie połączyć się z urządzeniem za pomocą adb connect ip:port.

Połącz się bezprzewodowo z urządzeniem po pierwszym połączeniu USB (tylko opcja dostępna w Androidzie 10 i starszych)

Uwaga: ten przepływ pracy dotyczy też Androida 11 (i nowszych), z tym zastrzeżeniem, że wymaga też *początkowego* połączenia przez fizyczny USB.

Uwaga: te instrukcje nie dotyczą urządzeń Wear z Androidem 10 (poziom interfejsu API 29) lub starszym. Więcej informacji znajdziesz w przewodniku na temat debugowania aplikacji na Wear OS.

adb zwykle komunikuje się z urządzeniem przez USB, ale możesz też użyć adb przez Wi-Fi. Aby podłączyć urządzenie z Androidem 10 (poziom interfejsu API 29) lub starszym, wykonaj te wstępne czynności przez USB:

1. Połącz urządzenie z Androidem i komputer hosta adb do wspólnej sieci Wi-Fi.

Uwaga: pamiętaj, że nie wszystkie punkty dostępu są odpowiednie. Konieczne może być użycie punktu dostępu, który ma prawidłowo skonfigurowaną zaporę sieciową do obsługi adb.

2. Podłącz urządzenie do komputera hosta za pomocą kabla USB.
3. Ustaw urządzenie docelowe, aby nasłuchiwało połączenia TCP/IP na porcie 5555:

   adb tcpip 5555
   

4. Odłącz kabel USB od urządzenia docelowego.
5. Znajdź adres IP urządzenia z Androidem. Na przykład na urządzeniu Nexus adres IP można znaleźć, wybierając kolejno Ustawienia > Informacje o tablecie (lub Informacje o telefonie) > Stan > Adres IP.
6. Połącz się z urządzeniem za pomocą adresu IP:

   adb connect device_ip_address:5555
   

7. Sprawdź, czy komputer hosta jest podłączony do urządzenia docelowego:

   $ adb devices
   List of devices attached
   device_ip_address:5555 device
   

Twoje urządzenie jest teraz połączone z aplikacją adb.

Jeśli połączenie adb z urządzeniem zostanie utracone:

• Upewnij się, że host jest nadal połączony z tą samą siecią Wi-Fi co Twoje urządzenie z Androidem.
• Połącz się ponownie, jeszcze raz wykonując krok adb connect.
• Jeśli to nie pomoże, zresetuj hosta adb:

  adb kill-server
  

  Potem trzeba zacząć od początku.

Zapytanie dotyczące urządzeń

Przed wykonaniem poleceń adb warto wiedzieć, które instancje urządzeń są połączone z serwerem adb. Wygeneruj listę podłączonych urządzeń za pomocą polecenia devices:

  adb devices -l
  

W odpowiedzi adb wydrukuje te informacje o stanie dla każdego urządzenia:

• Numer seryjny:adb tworzy ciąg znaków, który jednoznacznie identyfikuje urządzenie na podstawie numeru portu. Oto przykładowy numer seryjny: emulator-5554
• Stan: urządzenie może mieć jeden z tych stanów połączenia:
  • offline: urządzenie nie jest połączone z siecią adb lub nie odpowiada.
  • device: urządzenie jest połączone z serwerem adb. Pamiętaj, że ten stan nie oznacza, że system Android jest w pełni uruchomiony i działa prawidłowo, ponieważ urządzenie łączy się z urządzeniem adb w trakcie uruchamiania systemu. Po uruchomieniu jest to normalny stan działania urządzenia.
  • no device: brak połączonych urządzeń.
• Opis: jeśli dołączysz opcję -l, polecenie devices poinformuje Cię, jakie jest urządzenie. Te informacje są przydatne, gdy masz podłączonych wiele urządzeń, dzięki czemu możesz je odróżnić.

W przykładzie poniżej widać polecenie devices i jego dane wyjściowe. Są 3 uruchomione urządzenia. Pierwsze 2 wiersze na liście to emulatory, a trzeci to urządzenie podłączone do komputera.

$ adb devices
List of devices attached
emulator-5556 device product:sdk_google_phone_x86_64 model:Android_SDK_built_for_x86_64 device:generic_x86_64
emulator-5554 device product:sdk_google_phone_x86 model:Android_SDK_built_for_x86 device:generic_x86
0a388e93      device usb:1-1 product:razor model:Nexus_7 device:flo

Nie ma emulatora na liście

Polecenie adb devices zawiera sekwencję poleceń z wielkością liter, która sprawia, że uruchomione emulatory nie wyświetlają się w danych wyjściowych adb devices, mimo że są one widoczne na komputerze. Dzieje się tak, gdy są spełnione wszystkie te warunki:

• Serwer adb nie jest uruchomiony.
• Użyjesz polecenia emulator z opcją -port lub -ports z wartością portu o nieparzystych numerach z zakresu od 5554 do 5584.
• Wybrany port z nieparzystymi numerami nie jest zajęty, więc można nawiązać połączenie z podanym numerem portu. Jeśli jest on zajęty, emulator przełącza się na inny port, który spełnia wymagania podane w punkcie 2.
• Serwer adb uruchamiasz po uruchomieniu emulatora.

Jednym ze sposobów uniknięcia takiej sytuacji jest zezwolenie emulatorowi na wybór własnych portów i uruchamianie maksymalnie 16 emulatorów jednocześnie. Innym sposobem jest uruchamianie serwera adb zawsze przed użyciem polecenia emulator, zgodnie z poniższymi przykładami.

Przykład 1: w tej sekwencji poleceń polecenie adb devices uruchamia serwer adb, ale lista urządzeń nie wyświetla się.

Zatrzymaj serwer adb i wpisz poniższe polecenia w podanej kolejności. Jako nazwę AVD podaj prawidłową nazwę AVD z systemu. Aby uzyskać listę nazw AVD, wpisz emulator -list-avds. Polecenie emulator znajduje się w katalogu android_sdk/tools.

$ adb kill-server
$ emulator -avd Nexus_6_API_25 -port 5555
$ adb devices

List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *

Przykład 2: w tej sekwencji poleceń adb devices wyświetla listę urządzeń, ponieważ najpierw został uruchomiony serwer adb.

Aby zobaczyć emulator w danych wyjściowych adb devices, zatrzymaj serwer adb, a następnie uruchom go ponownie po użyciu polecenia emulator, a przed użyciem polecenia adb devices w ten sposób:

$ adb kill-server
$ emulator -avd Nexus_6_API_25 -port 5557
$ adb start-server
$ adb devices

List of devices attached
emulator-5557 device

Więcej informacji o opcjach uruchamiania emulatora znajdziesz w artykule Opcje uruchamiania wiersza poleceń.

Wysyłanie poleceń na określone urządzenie

Jeśli uruchomionych jest wiele urządzeń, w poleceniu adb musisz podać urządzenie docelowe. Aby określić cel:

1. Użyj polecenia devices, aby uzyskać numer seryjny środowiska docelowego.
2. Gdy uzyskasz numer seryjny, użyj opcji -s z poleceniami adb, aby podać numer seryjny.
   1. Jeśli zamierzasz wydać wiele poleceń adb, możesz ustawić zmienną środowiskową $ANDROID_SERIAL tak, aby zawierała numer seryjny.
   2. Jeśli używasz zarówno -s, jak i $ANDROID_SERIAL, -s zastępuje $ANDROID_SERIAL.

W poniższym przykładzie uzyskuje się listę podłączonych urządzeń, a numer seryjny jednego z urządzeń służy do zainstalowania na nim helloWorld.apk:

$ adb devices
List of devices attached
emulator-5554 device
emulator-5555 device
0.0.0.0:6520  device

# To install on emulator-5555
$ adb -s emulator-5555 install helloWorld.apk
# To install on 0.0.0.0:6520
$ adb -s 0.0.0.0:6520 install helloWorld.apk

Uwaga: jeśli wydasz polecenie bez wskazania urządzenia docelowego, gdy dostępnych jest kilka urządzeń, adb wyświetli błąd „adb: więcej niż jedno urządzenie/emulator”.

Jeśli masz dostępnych wiele urządzeń, ale tylko jedno jest emulatorem, użyj opcji -e, aby wysyłać polecenia do emulatora. Jeśli jest wiele urządzeń, ale tylko 1 urządzenie jest podłączone, użyj opcji -d, aby wysyłać polecenia do urządzenia.

Instalowanie aplikacji

Aby zainstalować plik APK w emulatorze lub na połączonym urządzeniu, użyj narzędzia adb za pomocą polecenia install:

adb install path_to_apk

Podczas instalowania testowego pakietu APK musisz użyć opcji -t w poleceniu install. Więcej informacji: -t.

Aby zainstalować wiele plików APK, użyj polecenia install-multiple. Jest to przydatne, gdy z Konsoli Play pobierasz wszystkie pliki APK aplikacji na konkretne urządzenie i chcesz je zainstalować w emulatorze lub na urządzeniu fizycznym.

Więcej informacji o tworzeniu pliku APK do zainstalowania w emulatorze lub instancji urządzenia znajdziesz w artykule Tworzenie i uruchamianie aplikacji.

Uwaga: jeśli korzystasz z Android Studio, nie musisz używać adb bezpośrednio, aby zainstalować aplikację w emulatorze lub na urządzeniu. Zamiast tego Android Studio zajmuje się pakowaniem i instalacją aplikacji za Ciebie.

Skonfiguruj przekierowanie portów

Za pomocą polecenia forward skonfiguruj dowolne przekierowanie portów, które przekazuje żądania z określonego hosta na inny port w urządzeniu. Poniżej znajduje się przykład konfigurowania przekierowania hosta z portu 6100 na port 7100 urządzenia:

adb forward tcp:6100 tcp:7100

Ten przykład konfiguruje przekierowanie hosta portu 6100 na adres local:logd:

adb forward tcp:6100 local:logd

Może to być przydatne, gdy chcesz ustalić, co jest wysyłane do określonego portu urządzenia. Wszystkie odebrane dane będą zapisywane w demonie logowania systemowego i wyświetlane w logach urządzenia.

Kopiowanie plików z urządzenia i na urządzenie

Do kopiowania plików z urządzenia i na urządzenie używaj poleceń pull i push. W przeciwieństwie do polecenia install, które kopiuje plik APK tylko do określonej lokalizacji, polecenia pull i push umożliwiają kopiowanie dowolnych katalogów i plików do dowolnego miejsca na urządzeniu.

Aby skopiować plik lub katalog i jego podkatalogi z urządzenia, wykonaj te czynności:

adb pull remote local

Aby skopiować plik lub katalog i jego podkatalogi na urządzenie, wykonaj te czynności:

adb push local remote

Zastąp local i remote ścieżkami do plików/katalogu docelowego na komputerze programisty (lokalnym) i na urządzeniu (zdalnie). Przykład:

adb push myfile.txt /sdcard/myfile.txt

Zatrzymywanie serwera adb

W niektórych przypadkach może być konieczne przerwanie procesu serwera adb i ponowne jego uruchomienie w celu rozwiązania problemu. Może się tak zdarzyć, jeśli na przykład adb nie odpowiada na polecenie.

Aby zatrzymać serwer adb, użyj polecenia adb kill-server. Następnie możesz ponownie uruchomić serwer, wykonując dowolne inne polecenie adb.

Wydaj polecenia adb

Wykonaj polecenia adb w wierszu poleceń na maszynie, której używasz do programowania lub ze skryptu, używając tego:

adb [-d | -e | -s serial_number] command

Jeśli uruchomiony jest tylko 1 emulator lub podłączone jest tylko 1 urządzenie, polecenie adb jest domyślnie wysyłane do tego urządzenia. Jeśli uruchomionych jest kilka emulatorów lub podłączonych jest kilka urządzeń, użyj opcji -d, -e lub -s, aby określić urządzenie docelowe, na które polecenie ma być kierowane.

Aby wyświetlić szczegółową listę wszystkich obsługiwanych poleceń adb, użyj tego polecenia:

adb --help

Wydaj polecenia powłoki

Za pomocą polecenia shell możesz wydawać polecenia dotyczące urządzeń za pomocą adb lub uruchomić interaktywną powłokę. Aby wygenerować jedno polecenie, użyj tego polecenia shell:

adb [-d |-e | -s serial_number] shell shell_command

Aby uruchomić interaktywną powłokę na urządzeniu, użyj tego polecenia shell:

adb [-d | -e | -s serial_number] shell

Aby zamknąć interaktywną powłokę, naciśnij Control+D lub wpisz exit.

Android zapewnia większość standardowych narzędzi wiersza poleceń Unix. Aby wyświetlić listę dostępnych narzędzi, użyj tego polecenia:

adb shell ls /system/bin

W przypadku większości poleceń pomoc jest dostępna za pomocą argumentu --help. Wiele poleceń powłoki znajduje się w toybox. Ogólną pomoc dotyczącą wszystkich poleceń ze skrzynią z zabawkami można uzyskać pod adresem toybox --help.

W Android Platform Tools w wersji 23 lub nowszej adb obsługuje argumenty tak samo jak polecenie ssh(1). Ta zmiana rozwiązała wiele problemów z wstrzykiwaniem poleceń i umożliwiła bezpieczne wykonywanie poleceń zawierających metaznaki powłoki, takich jak adb install Let\'sGo.apk. Ta zmiana oznacza, że zmieniła się również interpretacja poleceń zawierających metaznaki powłoki.

Na przykład adb shell setprop key 'two words' jest błędem, ponieważ cudzysłowy są pomijane przez powłokę lokalną, a urządzenie wykrywa adb shell setprop key two words. Aby polecenie zadziałało, cytuj 2 razy: raz dla powłoki lokalnej i raz dla powłoki zdalnej (tak jak w przypadku ssh(1)). Na przykład adb shell setprop key "'two words'" działa, ponieważ lokalna powłoka przyjmuje zewnętrzny poziom cytowania, a urządzenie nadal widzi wewnętrzny poziom cytowania: setprop key 'two words'. Zmiana znaczenia również jest możliwa, ale podwójne cytowanie jest zwykle łatwiejsze.

Zapoznaj się też z narzędziem wiersza poleceń Logcat, które przydaje się do monitorowania logu systemowego.

Menedżer aktywności związanej z połączeniami

W powłoce adb możesz używać narzędzia Menedżer aktywności (am), aby wydawać polecenia do wykonywania różnych działań systemowych, takich jak rozpoczęcie działania, wymuszenie zatrzymania, transmitowanie intencji, modyfikacja właściwości ekranu urządzenia itp.

W powłoce składnia am to:

am command

Polecenie menedżera aktywności możesz też wydać bezpośrednio w adb bez wpisywania zdalnej powłoki. Przykład:

adb shell am start -a android.intent.action.VIEW

Tabela 1. Dostępne polecenia menedżera aktywności

Specyfikacja argumentów intencji

W przypadku poleceń menedżera aktywności, które przyjmują argument intent, możesz określić intencję za pomocą tych opcji:

Menedżer pakietów połączeń (pm)

W powłoce adb możesz używać narzędzia menedżera pakietów (pm), aby wykonywać działania i zapytania dotyczące pakietów aplikacji zainstalowanych na urządzeniu.

W powłoce składnia pm to:

pm command

Możesz też wydać polecenie menedżera pakietów bezpośrednio z poziomu adb bez wpisywania zdalnej powłoki. Przykład:

adb shell pm uninstall com.example.MyApp

Tabela 2. Dostępne polecenia menedżera pakietów

Zadzwoń do menedżera zasad dotyczących urządzeń (dpm)

Aby ułatwić tworzenie i testowanie aplikacji do zarządzania urządzeniami, możesz wysyłać polecenia do narzędzia Menedżer zasad dotyczących urządzeń (dpm). Za pomocą tego narzędzia możesz kontrolować aktywną aplikację administratora i zmieniać dane o stanie zasad na urządzeniu.

W powłoce składnia dpm to:

dpm command

Polecenie menedżera zasad dotyczących urządzeń możesz też wykonać bezpośrednio z poziomu adb bez wpisywania zdalnej powłoki:

adb shell dpm command

Tabela 3. Dostępne polecenia menedżera zasad dotyczących urządzeń

Zrób zrzut ekranu

Polecenie screencap to narzędzie powłoki służące do wykonywania zrzutu ekranu wyświetlacza urządzenia.

W powłoce składnia screencap to:

screencap filename

Aby użyć polecenia screencap z poziomu wiersza poleceń, wpisz:

adb shell screencap /sdcard/screen.png

Oto przykładowa sesja zrzutu ekranu, w której wykorzystano powłokę adb do przechwycenia zrzutu ekranu i polecenie pull w celu pobrania pliku z urządzenia:

$ adb shell
shell@ $ screencap /sdcard/screen.png
shell@ $ exit
$ adb pull /sdcard/screen.png

Nagraj film

Polecenie screenrecord to narzędzie powłoki służące do rejestrowania wyświetlania urządzeń z Androidem 4.4 (poziom interfejsu API 19) lub nowszym. Narzędzie rejestruje aktywność związaną z ekranem w pliku MPEG-4. Możesz użyć tego pliku do tworzenia filmów promocyjnych i szkoleniowych, a także do debugowania i testowania.

W powłoce użyj tej składni:

screenrecord [options] filename

Aby użyć polecenia screenrecord z poziomu wiersza poleceń, wpisz:

adb shell screenrecord /sdcard/demo.mp4

Zatrzymaj nagrywanie ekranu, naciskając Control+C. W przeciwnym razie nagrywanie zatrzymuje się automatycznie po 3 minutach lub po upływie limitu czasu ustawionego przez --time-limit.

Aby rozpocząć nagrywanie ekranu urządzenia, uruchom polecenie screenrecord, aby nagrać film. Następnie uruchom polecenie pull, aby pobrać film z urządzenia na komputer hosta. Oto przykładowa sesja nagraniowa:

$ adb shell
shell@ $ screenrecord --verbose /sdcard/demo.mp4
(press Control + C to stop)
shell@ $ exit
$ adb pull /sdcard/demo.mp4

Narzędzie screenrecord może nagrywać w dowolnej obsługiwanej rozdzielczości i szybkości transmisji bitów, zachowując proporcje obrazu wyświetlacza urządzenia. Narzędzie domyślnie rejestruje rozdzielczość i orientację ekranu natywnego (maksymalnie 3 minuty).

Ograniczenia narzędzia screenrecord:

• Dźwięk nie jest nagrywany z plikiem wideo.
• Nagrywanie filmów jest niedostępne na urządzeniach z Wear OS.
• Niektóre urządzenia mogą nie mieć możliwości nagrywania w rozdzielczości wyświetlacza. Jeśli napotkasz problemy z nagrywaniem ekranu, spróbuj ustawić niższą rozdzielczość.
• Obracanie ekranu podczas nagrywania nie jest obsługiwane. Jeśli ekran obróci się podczas nagrywania, część ekranu zostanie ucięta.

Tabela 4. screenrecord – opcje

screenrecord --bit-rate 6000000 /sdcard/demo.mp4

Odczytywanie profili ART w aplikacjach

Począwszy od Androida w wersji 7.0 (poziom interfejsu API 24), środowisko wykonawcze Android (ART) zbiera profile wykonywania zainstalowanych aplikacji, które służą do optymalizacji wydajności aplikacji. Sprawdź zebrane profile, aby dowiedzieć się, które metody są często wykonywane i które klasy są używane podczas uruchamiania aplikacji.

Uwaga: nazwę pliku profilu wykonywania można pobrać tylko wtedy, gdy masz dostęp do systemu plików na poziomie roota, na przykład w emulatorze.

Aby wygenerować informacje o profilu w formie tekstowej, użyj tego polecenia:

adb shell cmd package dump-profiles package

Aby pobrać utworzony plik, użyj polecenia:

adb pull /data/misc/profman/package.prof.txt

Zresetuj urządzenia testowe

Jeśli testujesz aplikację na wielu urządzeniach testowych, warto resetować urządzenie między kolejnymi testami, aby na przykład usunąć dane użytkownika i zresetować środowisko testowe. Możesz przywrócić ustawienia fabryczne urządzenia testowego z Androidem 10 (poziom interfejsu API 29) lub nowszym, korzystając z polecenia powłoki testharness adb, jak w tym przykładzie:

adb shell cmd testharness enable

Podczas przywracania urządzenia przy użyciu funkcji testharness urządzenie automatycznie tworzy kopię zapasową klucza RSA, który umożliwia debugowanie z użyciem bieżącej stacji roboczej w stałej lokalizacji. Oznacza to, że po zresetowaniu urządzenia stacja robocza może kontynuować debugowanie i wysyłać do urządzenia polecenia adb bez ręcznego rejestrowania nowego klucza.

Aby ułatwić i zwiększyć bezpieczeństwo testowania aplikacji, użycie polecenia testharness do przywrócenia urządzenia powoduje też zmianę tych ustawień:

• Na urządzeniu są skonfigurowane pewne ustawienia systemowe, tak aby kreatory wstępnej konfiguracji urządzenia nie były wyświetlane. Oznacza to, że urządzenie przechodzi w stan, w którym możesz szybko zainstalować, debugować i testować aplikację.
• Ustawienia:
  • Wyłącza ekran blokady.
  • Wyłącza alerty o zagrożeniu.
  • Wyłącza autosynchronizację kont.
  • Wyłącza automatyczne aktualizacje systemu.
• Inne:
  • Wyłącza wstępnie zainstalowane aplikacje zabezpieczające.

Jeśli aplikacja musi wykryć domyślne ustawienia polecenia testharness i dostosować się do nich, użyj ActivityManager.isRunningInUserTestHarness().

SQLite

sqlite3 uruchamia program wiersza poleceń sqlite do badania baz danych SQLite. Zawiera polecenia takie jak .dump do drukowania zawartości tabeli i .schema do drukowania instrukcji SQL CREATE dla istniejącej tabeli. Możesz też wykonać polecenia SQLite z poziomu wiersza poleceń, jak pokazano poniżej:

$ adb -s emulator-5554 shell
$ sqlite3 /data/data/com.example.app/databases/rssitems.db
SQLite version 3.3.12
Enter ".help" for instructions

Uwaga: dostęp do bazy danych SQLite jest możliwy tylko wtedy, gdy masz dostęp do systemu plików na poziomie roota, na przykład w emulatorze.

Więcej informacji znajdziesz w dokumentacji wiersza poleceń sqlite3.

Backendy adb USB

Serwer adb może wchodzić w interakcję ze stosem USB za pomocą 2 backendów. Może korzystać z natywnego backendu systemu operacyjnego (Windows, Linux lub macOS) lub z backendu libusb. Niektóre funkcje, takie jak attach, detach i wykrywanie szybkości przez USB, są dostępne tylko wtedy, gdy korzystasz z backendu libusb.

Możesz wybrać backend, korzystając ze zmiennej środowiskowej ADB_LIBUSB. Jeśli nie jest skonfigurowana, adb używa domyślnego backendu. Domyślne działanie różni się w zależności od systemu operacyjnego. Począwszy od ADB w wersji 34 domyślnie backend liubusb jest używany we wszystkich systemach operacyjnych oprócz Windows, w którym domyślnie jest używany natywny backend. Ustawienie ADB_LIBUSB określa, czy używany jest natywny backend czy libusb. Więcej informacji o zmiennych środowiskowych adb znajdziesz na stronie z ręczną konfiguracją adb.

Backendy adb mDNS

ADB może używać protokołu DNS multicast do automatycznego łączenia serwera i urządzeń. Serwer ADB jest wyposażony w dwa backendy: Bonjour (Apple mdnsResponder) oraz Openscreen.

Backend Bonjour wymaga uruchomienia demona na hoście. Wbudowany demon Apple w systemie macOS zawsze działa, ale w systemach Windows i Linux użytkownik musi upewnić się, że demon mdnsd jest włączony. Jeśli polecenie adb mdns check zwróci błąd, prawdopodobnie ADB korzysta z backendu Bonjour, ale nie działa żaden demon Bonjour.

Backend Openscreen nie wymaga demona do działania na komputerze. Obsługa backendu Openscreen w systemie macOS zaczyna się od ADB w wersji 35. Systemy Windows i Linux są obsługiwane od wersji ADB 34.

Domyślnie ADB korzysta z backendu Bonjour. To zachowanie można zmienić za pomocą zmiennej środowiskowej ADB_MDNS_OPENSCREEN (ustawionej na 1 lub 0). Więcej informacji znajdziesz na stronie z ręczną konfiguracją ADB.

Tryb adb Burst (zaczynający się od ADB 36.0.0)

Tryb Burst to eksperymentalna funkcja, która pozwala ADB kontynuować wysyłanie pakietów do urządzenia, jeszcze zanim urządzenie zareaguje na poprzedni pakiet. Znacznie zwiększa to przepustowość ADB podczas przenoszenia dużych plików i skraca czas oczekiwania podczas debugowania.

Tryb serii jest domyślnie wyłączony. Aby włączyć tę funkcję, wykonaj jedną z tych czynności:

• Ustaw zmienną środowiskową ADB_DELAYED_ACK na 1.
• W Android Studio przejdź do ustawień debugera w sekcji Plik (lub Android Studio w systemie macOS) > Ustawienia > Kompilacja, wykonywanie, wdrażanie > Debuger i ustaw opcję Tryb ADB Server Burst Mode na Włączony.