Android Debug Bridge (adb)

Android Debug Bridge (adb) to wszechstronne narzędzie wiersza poleceń, które umożliwia komunikację z urządzeniem. Polecenie adb ułatwia wykonywanie różnych działań na urządzeniu, takich jak instalowanie i debugowanie aplikacji. adb zapewnia dostęp do powłoki systemu Unix, której możesz używać do uruchamiania na urządzeniu różnych poleceń. Jest to program typu klient-serwer, który obejmuje 3 komponenty:

• klient, który wysyła polecenia; Klient działa na Twoim komputerze deweloperskim. Klienta możesz wywołać z terminala wiersza poleceń, wydając polecenie adb.
• Usługa (adbd), która uruchamia polecenia na urządzeniu. Demon działa w tle na każdym urządzeniu.
• serwer, który zarządza komunikacją między klientem a demonem; Serwer działa jako proces w tle na komputerze używanym do programowania.

adb jest częścią pakietu narzędzi platformy Android SDK. Pobierz ten pakiet za pomocą Menedżera SDK, który zainstaluje go w lokalizacji android_sdk/platform-tools/. Jeśli chcesz pobrać samodzielny pakiet narzędzi platformy Android SDK, kliknij tutaj.

Informacje o łączeniu urządzenia do użytku w adb, w tym o tym, jak używać Asystenta połączenia do rozwiązywania typowych problemów, znajdziesz w artykule Uruchamianie aplikacji na urządzeniu.

Jak działa adb

Gdy uruchamiasz klienta adb, najpierw sprawdza on, czy proces serwera adb jest już uruchomiony. Jeśli nie, uruchamia proces serwera. Po uruchomieniu serwer wiąże się z lokalnym portem TCP 5037 i nasłuchuje poleceń wysyłanych przez klienty adb.

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

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

Każdy emulator używa pary kolejnych portów – portu o parzystym numerze do połączeń z konsolą i portu o nieparzystym numerze do połączeń adb. Przykład:

Emulator 1, konsola: 5554
Emulator 1, adb: 5555
Emulator 2, konsola: 5556
Emulator 2, adb: 5557
itd.

Jak widać, emulator połączony z adb na porcie 5555 to ten sam emulator, którego konsola nasłuchuje na porcie 5554.

Gdy serwer skonfiguruje połączenia ze wszystkimi urządzeniami, możesz używać poleceń adb, aby uzyskać dostęp do tych urządzeń. Serwer zarządza połączeniami z urządzeniami i obsługuje polecenia z wielu adbklientów, więc możesz sterować dowolnym urządzeniem z dowolnego klienta lub ze skryptu.

Włącz debugowanie adb na urządzeniu.

Aby używać adb z urządzeniem podłączonym przez USB, musisz włączyć debugowanie USB w ustawieniach systemowych urządzenia w sekcji Opcje programisty. Na Androidzie 4.2 (API na poziomie 17) i nowszych wersjach ekran Opcje programisty jest domyślnie ukryty. Aby ją wyświetlić, włącz Opcje programisty.

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

Uwaga: gdy podłączysz urządzenie z Androidem 4.2.2 (poziom interfejsu API 17) lub nowszym, system wyświetli okno dialogowe z pytaniem, czy zaakceptować klucz RSA, który umożliwia debugowanie na tym komputerze. Ten mechanizm zabezpieczeń chroni urządzenia użytkowników, ponieważ zapewnia, że debugowanie przez USB i inne polecenia adb nie mogą być wykonywane, dopóki nie odblokujesz urządzenia i nie potwierdzisz okna dialogowego.

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

Łączenie z urządzeniem przez Wi-Fi

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

Android 11 (poziom interfejsu API 30) i nowsze wersje obsługują wdrażanie i debugowanie aplikacji bezprzewodowo ze stacji roboczej za pomocą Android Debug Bridge (adb). Możesz na przykład wdrożyć aplikację z możliwością debugowania na wielu urządzeniach zdalnych bez konieczności fizycznego podłączania urządzenia przez USB. Eliminuje to konieczność rozwiązywania typowych problemów z połączeniem USB, takich jak instalacja sterownika.

Android 17 wraz z adb 37.0.0 wprowadza adb Wi-Fi 2.0, który rozwiązuje wiele problemów z użytecznością poprzedniej wersji. Urządzenie automatycznie połączy się ze stacją roboczą, gdy połączy się z zaufaną siecią bezprzewodową do debugowania.

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

• Sprawdź, czy stacja robocza i urządzenie są połączone z tą samą siecią bezprzewodową.

• Upewnij się, że na telefonie masz Androida 11 (API na poziomie 30) lub nowszego, a na telewizorze i zegarku z Wear OS – Androida 13 (API na poziomie 33) lub nowszego. Więcej informacji znajdziesz w artykule Sprawdzanie i aktualizowanie wersji Androida.

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

Aby używać 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 sparować urządzenie, wykonaj te czynności:

Uwaga: urządzenie wystarczy sparować ze stacją roboczą tylko raz. Urządzenie pozostanie sparowane ze stacją roboczą, dopóki nie zapomnisz go lub nie cofniesz autoryzacji debugowania ADB na urządzeniu. Urządzenie i stacja robocza połączą się automatycznie, gdy będą w tej samej sieci.

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

2. Na urządzeniu kliknij Debugowanie bezprzewodowe:

   

   Rysunek 1. Potwierdzenie debugowania bezprzewodowego na telefonie Google Pixel.

3. Zezwól na debugowanie bezprzewodowe w swojej sieci. Pamiętaj, że zaznaczenie pola wyboru Zawsze zezwalaj w tej sieci sprawia, że sieć staje się zaufaną siecią bezprzewodową do debugowania. Urządzenie zawsze zezwoli na debugowanie bezprzewodowe w tej sieci, gdy tylko się z nią połączy.



Rysunek 2. Ustawienie Debugowanie bezprzewodowe na telefonie Pixel.

Uwaga: użytkownicy Androida Studio mogą sparować urządzenie za pomocą kodu QR. Wystarczy, że wybiorą Sparuj urządzenie za pomocą kodu QR i zeskanują kod QR uzyskany z okna dialogowego Sparuj urządzenia przez Wi-Fi w Androidzie Studio.

4. Na urządzeniu wybierz Sparuj przy pomocy kodu parowania i zanotuj adres IP, numer portu oraz kod parowania wyświetlane na urządzeniu.

5. Na stacji roboczej otwórz okno terminala i przejdź do katalogu android_sdk/platform-tools.

6. W terminalu stacji roboczej uruchom adb pair ipaddr:port. Użyj adresu IP i numeru portu podanych powyżej.

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

   

   Rysunek 3. Pojawi się komunikat informujący o pomyślnym sparowaniu urządzenia.

8. Po sparowaniu urządzenia sprawdź, czy jest ono połączone.Urządzenie możesz teraz używać bezprzewodowo, tak jak w przypadku połączenia USB.

   Aby odłączyć stację roboczą, na urządzeniu otwórz Debugowanie bezprzewodowe. Kliknij nazwę stacji roboczej w sekcji Sparowane urządzenia i wybierz Zapomnij. Możesz też kliknąć Cofnij autoryzacje debugowania ADB na stronie Ustawienia urządzenia, aby odłączyć stację roboczą i wszystkie inne wcześniej sparowane stacje robocze.

9. Jeśli chcesz szybko włączać i wyłączać debugowanie bezprzewodowe, możesz użyć kafelków szybkich ustawień dla programisty w sekcji Opcje programisty > Kafelki szybkich ustawień dla programisty.

   

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

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

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

Sprawdź, czy 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 konfiguracja adb na stacji roboczej jest prawidłowa.

Aby sprawdzić, czy konfiguracja ADB na stacji roboczej jest prawidłowa, otwórz terminal na stacji roboczej i wpisz adb server-status. Sprawdź, czy dane wyjściowe zawierają te informacje:

• version: "37.0.0" lub nowsza: jeśli tak nie jest, pobierz najnowszą wersję narzędzi platformy SDK.
• mdns_enabled: true: jeśli ta opcja jest ustawiona na false, adb nie będzie w stanie automatycznie wykrywać urządzeń w Twojej sieci. Aby rozwiązać ten problem, musisz ustawić zmienną środowiskową ADB_MDNS na 1, a następnie ponownie uruchomić serwer adb, wykonując polecenia adb kill-server i adb start-server.
• mdns_backend: LIBADBMDNS: jeśli tak nie jest, adb używa przestarzałej biblioteki do automatycznego wykrywania urządzeń w sieci. Aby rozwiązać ten problem, musisz ustawić zmienną środowiskową ADB_MDNS_OPENSCREEN na 0, a następnie ponownie uruchomić serwer adb, wykonując polecenia adb kill-server i adb start-server.

Sprawdź, czy Twoja sieć obsługuje mDNS

adb korzysta z mDNS, aby automatycznie wykrywać sparowane urządzenia i się z nimi łączyć. Aby sprawdzić, czy Twoja sieć obsługuje mDNS:

1. Na urządzeniu włącz debugowanie bezprzewodowe zgodnie z opisem w sekcji Łączenie z urządzeniem przez Wi-Fi.

2. Na stacji roboczej otwórz terminal i wpisz adb mdns track-services --proto-text.

3. Sprawdź, czy dane wyjściowe nie są puste i zawierają usługę TLS z adresem IP i numerem portu urządzenia. Jeśli wynik jest pusty, Twoja sieć nie obsługuje mDNS. Przykładowe dane wyjściowe:

   tls {
     service {
       instance: "adb-35121FDJH000R8-xyMD0H"
       service: "_adb-tls-connect._tcp"
       ipv4: "192.168.84.23"
       ipv6: "fe80:0:0:0:fc7a:299d:8d38:6c1c"
       port: 37895
       product_model: "Pixel 8"
       build_version_sdk_full: "37.0"
       given_name: "sherifeid Pixel"
       serial: "35121FDJH000R8"
       mdns_service_version: "2.0"
       hostname: "Android_CXUKYJY1.local"
     }
   }
             

Sprawdź, czy Twoje urządzenie obsługuje ADB Wi-Fi 2.0.

Uwaga: ADB Wi-Fi 2.0 jest obsługiwane na Androidzie 17 i nowszych.

Aby sprawdzić, czy Twoje urządzenie obsługuje ADB Wi-Fi 2.0:

1. Na urządzeniu włącz debugowanie bezprzewodowe zgodnie z opisem w sekcji Łączenie z urządzeniem przez Wi-Fi.

2. Na stacji roboczej otwórz terminal i wpisz adb mdns track-services --proto-text.

3. Sprawdź, czy wynik zawiera wartość mdns_service_version: "2.0" lub wyższą. Jeśli tak nie jest, oznacza to, że na urządzeniu nie jest zainstalowany Android 17 lub nowszy i nie obsługuje on ADB Wi-Fi 2.0. Aby zaktualizować system do Androida 17 lub nowszego, sprawdź, czy na urządzeniu są oczekujące aktualizacje systemu. Sprawdź i zaktualizuj wersję Androida.

Zgłaszanie nowego problemu

Jeśli nadal masz problemy z połączeniem bezprzewodowym z urządzeniem, możesz zgłosić nowy problem. W zgłoszeniu podaj te informacje:

• Dzienniki z urządzenia: odtwórz problem i dołącz dzienniki urządzenia.
• Logi z adb na stacji roboczej:
  1. Ustaw zmienną środowiskową ADB_TRACE=all.
  2. Uruchom ponownie serwer adb, wpisując polecenie adb kill-server, a potem adb start-server.
  3. Odtwórz problem.
  4. Znajdź pliki dziennika: uruchom adb server-status i załącz plik dziennika, do którego odwołuje się wynik log_absolute_path.

Połączenie bezprzewodowe z urządzeniem po pierwszym połączeniu przez USB (jedyna opcja dostępna na urządzeniach z Androidem 10 i starszym)

Uwaga: ten proces dotyczy też Androida 11 (i nowszych wersji), z tym zastrzeżeniem, że obejmuje on również *początkowe* połączenie przez fizyczne złącze USB.

Uwaga: poniższe instrukcje nie dotyczą urządzeń Wear z Androidem 10 (API na poziomie 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żywać adb przez Wi-Fi. Aby połączyć urządzenie z Androidem 10 (API na poziomie 29) lub starszym, wykonaj te wstępne czynności przez USB:

1. Połącz urządzenie z Androidem i adbkomputer hosta z tą samą siecią Wi-Fi.

Uwaga: nie wszystkie punkty dostępu są odpowiednie. Konieczne może być użycie punktu dostępu, którego zapora sieciowa jest prawidłowo skonfigurowana do obsługi adb.

2. Podłącz urządzenie do komputera hosta za pomocą kabla USB.
3. Skonfiguruj urządzenie docelowe tak, 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 znajdziesz w sekcji Ustawienia > Informacje o tablecie (lub Informacje o telefonie) > Stan > Adres IP.
6. Połącz się z urządzeniem za pomocą jego adresu IP:

   adb connect device_ip_address:5555
   

7. Sprawdź, czy komputer host jest połączony z urządzeniem docelowym:

   $ adb devices
   List of devices attached
   device_ip_address:5555 device
   

Urządzenie jest teraz połączone z urządzeniem adb.

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

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

  adb kill-server
  

  Następnie zacznij od początku.

Wysyłanie zapytania dotyczącego urządzeń

Przed wydaniem 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 wyświetla informacje o stanie 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 – stan połączenia urządzenia może być jednym z tych stanów:
  • offline: urządzenie nie jest połączone z 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, ponieważ urządzenie łączy się z adb, gdy system jest jeszcze w trakcie uruchamiania. Po uruchomieniu jest to normalny stan operacyjny urządzenia.
  • no device: Brak podłączonych urządzeń.
• Opis: jeśli uwzględnisz opcję -l, polecenie devices poinformuje Cię, czym jest urządzenie. Te informacje są przydatne, gdy masz podłączonych kilka urządzeń, ponieważ pozwalają je odróżnić.

Poniższy przykład pokazuje polecenie devices i jego dane wyjściowe. Działają 3 urządzenia. Pierwsze 2 wiersze na liście to emulatory, a trzeci wiersz to urządzenie sprzętowe 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

Brak emulatora na liście

Polecenie adb devices ma sekwencję poleceń w przypadku, gdy działające emulatory nie są widoczne w danych wyjściowych polecenia adb devices, mimo że są widoczne na pulpicie. Dzieje się tak, gdy wszystkie te warunki są spełnione:

• Serwer adb nie działa.
• Użyj polecenia emulator z opcją -port lub -ports i nieparzystą wartością portu z zakresu od 5554 do 5584.
• Wybrany port o nieparzystym numerze nie jest zajęty, więc połączenie może zostać nawiązane na określonym porcie. Jeśli jednak jest zajęty, emulator przełącza się na inny port, który spełnia wymagania opisane w punkcie 2.
• Serwer adb uruchamia się po uruchomieniu emulatora.

Jednym ze sposobów uniknięcia tej sytuacji jest pozwolenie emulatorowi na wybór własnych portów i uruchamianie nie więcej niż 16 emulatorów jednocześnie. Innym sposobem jest zawsze uruchamianie serwera adb przed użyciem polecenia emulator, jak pokazano w przykładach poniżej.

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

Zatrzymaj serwer adb i wpisz te polecenia w podanej kolejności. W przypadku nazwy AVD podaj prawidłową nazwę AVD z systemu. Aby wyświetlić 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 poniższej sekwencji poleceń adb devices wyświetla listę urządzeń, ponieważ serwer adb został uruchomiony jako pierwszy.

Aby zobaczyć emulator w danych wyjściowych adb devices, zatrzymaj serwer adb, a następnie uruchom go ponownie po użyciu polecenia emulator i przed użyciem polecenia adb devices, jak pokazano poniżej:

$ 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 wiersza poleceń emulatora znajdziesz w sekcji Opcje uruchamiania w wierszu poleceń.

Wysyłanie poleceń do konkretnego urządzenia

Jeśli działa kilka urządzeń, musisz określić urządzenie docelowe, gdy wydajesz polecenie adb. Aby określić cel, wykonaj te czynności:

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

W poniższym przykładzie najpierw pobierana jest lista podłączonych urządzeń, a potem numer seryjny jednego z nich jest używany 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 określania urządzenia docelowego, gdy dostępnych jest wiele urządzeń, adb wyświetli błąd „adb: more than one device/emulator” (adb: więcej niż 1 urządzenie lub emulator).

Jeśli masz kilka urządzeń, ale tylko jedno z nich to emulator, użyj opcji -e, aby wysyłać polecenia do emulatora. Jeśli jest wiele urządzeń, ale tylko jedno urządzenie sprzętowe jest podłączone, użyj opcji -d, aby wysyłać polecenia do urządzenia sprzętowego.

Instalowanie aplikacji

Za pomocą polecenia install możesz zainstalować plik APK na emulatorze lub podłączonym urządzeniu:adb

adb install path_to_apk

Podczas instalowania testowego pliku APK musisz użyć opcji -t z poleceniem install. Więcej informacji znajdziesz w sekcji -t.

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

Więcej informacji o tworzeniu pliku APK, który można zainstalować na emulatorze lub instancji urządzenia, znajdziesz w artykule Kompilowanie i uruchamianie aplikacji.

Uwaga: jeśli używasz Androida Studio, nie musisz używać polecenia adb bezpośrednio, aby zainstalować aplikację na emulatorze lub urządzeniu. Android Studio zajmuje się pakowaniem i instalowaniem aplikacji.

Skonfiguruj przekierowanie portów

Użyj polecenia forward, aby skonfigurować dowolne przekierowanie portów, które przekazuje żądania na określonym porcie hosta do innego portu na urządzeniu. W tym przykładzie skonfigurujemy przekierowanie portu hosta 6100 na port urządzenia 7100:

adb forward tcp:6100 tcp:7100

W tym przykładzie skonfigurujemy przekazywanie portu hosta 6100 do lokalnego logd:

adb forward tcp:6100 local:logd

Może to być przydatne, jeśli chcesz sprawdzić, co jest wysyłane do danego portu na urządzeniu. Wszystkie otrzymane dane zostaną zapisane w demonach rejestrujących system i wyświetlone w dziennikach urządzenia.

Kopiowanie plików na urządzenie i z niego

Użyj poleceń pull i push, aby skopiować pliki na urządzenie i z niego. 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 dowolnej lokalizacji 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 lub katalogów docelowych na komputerze używanym do programowania (lokalnym) i na urządzeniu (zdalnym). Przykład:

adb push myfile.txt /sdcard/myfile.txt

Zatrzymywanie serwera adb

W niektórych przypadkach, aby rozwiązać problem, może być konieczne zakończenie procesu serwera adb i ponowne uruchomienie go. Może to mieć miejsce na przykład wtedy, gdy adb nie odpowiada na polecenie.

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

Wydawanie poleceń adb

Wydawaj polecenia adb z wiersza poleceń na komputerze używanym do programowania lub ze skryptu, używając tych poleceń:

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

Jeśli działa tylko 1 emulator lub jest podłączone tylko 1 urządzenie, polecenie adb jest domyślnie wysyłane do tego urządzenia. Jeśli działa wiele emulatorów lub jest podłączonych wiele urządzeń, musisz użyć opcji -d, -e lub -s, aby określić urządzenie docelowe, do którego ma być skierowane polecenie.

Szczegółową listę wszystkich obsługiwanych poleceń adb możesz wyświetlić za pomocą tego polecenia:

adb --help

Wydawanie poleceń powłoki

Za pomocą polecenia shell możesz wydawać polecenia urządzeniom za pomocą adb lub uruchamiać powłokę interaktywną. Aby wydać pojedyncze polecenie, użyj polecenia shell w ten sposób:

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

Aby uruchomić na urządzeniu powłokę interaktywną, użyj polecenia shell w ten sposób:

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

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

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

adb shell ls /system/bin

Pomoc jest dostępna w przypadku większości poleceń za pomocą argumentu --help. Wiele poleceń powłoki jest dostarczanych przez toybox. Ogólna pomoc dotycząca wszystkich poleceń toybox jest dostępna za pomocą argumentu toybox --help.

W narzędziach platformy Androida w wersji 23 i nowszych adb obsługuje argumenty w taki sam sposób jak polecenie ssh(1). Ta zmiana rozwiązała wiele problemów związanych z wstrzykiwaniem poleceń i umożliwia bezpieczne wykonywanie poleceń zawierających metaznaki powłoki, takie jak adb install Let\'sGo.apk. Ta zmiana oznacza, że zmieniła się też interpretacja każdego polecenia zawierającego metaznaki powłoki.

Na przykład adb shell setprop key 'two words' jest teraz błędem, ponieważ cudzysłowy są pochłaniane przez lokalną powłokę, a urządzenie widzi adb shell setprop key two words. Aby polecenie działało, umieść je w cudzysłowie dwukrotnie – raz dla powłoki lokalnej i raz dla powłoki zdalnej, tak jak w przypadku polecenia ssh(1). Na przykład polecenie adb shell setprop key "'two words'" działa, ponieważ powłoka lokalna przyjmuje zewnętrzny poziom cudzysłowu, a urządzenie nadal widzi wewnętrzny poziom cudzysłowu: setprop key 'two words'. Możesz też użyć znaku ucieczki, ale zwykle łatwiej jest użyć podwójnego cudzysłowu.

Zobacz też narzędzie wiersza poleceń Logcat, które jest przydatne do monitorowania dziennika systemowego.

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

W adbpowłoceam możesz wydawać polecenia za pomocą narzędzia menedżera aktywności (am), aby wykonywać różne działania systemowe, takie jak uruchamianie aktywności, wymuszanie zatrzymania procesu, wysyłanie intencji, modyfikowanie właściwości ekranu urządzenia i inne.

W powłoce składnia am jest następująca:

am command

Możesz też wydać polecenie menedżera aktywności bezpośrednio z adb bez wchodzenia do powłoki zdalnej. 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:

Wywołanie menedżera pakietów (pm)

W powłoce adb możesz wydawać polecenia za pomocą narzędzia do zarządzania pakietami (pm), aby wykonywać działania i zapytania dotyczące pakietów aplikacji zainstalowanych na urządzeniu.

W powłoce składnia pm jest następująca:

pm command

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

adb shell pm uninstall com.example.MyApp

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

Wywołanie menedżera zasad dotyczących urządzenia (dpm)

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

W powłoce składnia dpmjest następująca:

dpm command

Możesz też wydać polecenie menedżera zasad dotyczących urządzeń bezpośrednio z adb bez wchodzenia w zdalną powłokę:

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 robienia zrzutów ekranu urządzenia.

W powłoce składnia screencap jest następująca:

screencap filename

Aby użyć screencap z wiersza poleceń, wpisz to polecenie:

adb shell screencap /sdcard/screen.png

Oto przykład sesji zrzutu ekranu, w której do zrobienia zrzutu ekranu użyto powłoki adb, a do pobrania pliku z urządzenia – polecenia pull:

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

Jeśli pominiesz nazwę pliku, screencap zapisze obraz w standardowym wyjściu. W połączeniu z opcją -p, która określa format PNG, możesz przesyłać strumieniowo zrzut ekranu urządzenia bezpośrednio do pliku na komputerze lokalnym.

Oto przykład zrobienia zrzutu ekranu i zapisania go lokalnie za pomocą jednego polecenia:

# use 'exec-out' instead of 'shell' to get raw data
$ adb exec-out screencap -p > screen.png

Nagraj film

Polecenie screenrecord to narzędzie powłoki do nagrywania ekranu urządzeń z Androidem 4.4 (poziom interfejsu API 19) lub nowszym. Narzędzie rejestruje aktywność na ekranie w pliku MPEG-4. Możesz używać tego pliku do tworzenia filmów promocyjnych lub szkoleniowych albo do debugowania i testowania.

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

screenrecord [options] filename

Aby użyć screenrecord z wiersza poleceń, wpisz to polecenie:

adb shell screenrecord /sdcard/demo.mp4

Zatrzymaj nagrywanie ekranu, naciskając Ctrl+C. W przeciwnym razie nagrywanie zakończy 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ład sesji nagrywania:

$ 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, zachowując format obrazu wyświetlacza urządzenia. Domyślnie nagrywa w natywnej rozdzielczości i orientacji wyświetlacza, a maksymalna długość nagrania to 3 minuty.

Ograniczenia narzędzia screenrecord:

• Dźwięk nie jest nagrywany razem z plikiem wideo.
• Nagrywanie filmów nie jest dostępne na urządzeniach z Wear OS.
• Niektóre urządzenia mogą nie obsługiwać nagrywania w natywnej rozdzielczości wyświetlacza. Jeśli masz problemy z nagrywaniem ekranu, spróbuj użyć niższej rozdzielczości.
• Obracanie ekranu podczas nagrywania nie jest obsługiwane. Jeśli podczas nagrywania ekran się obróci, część ekranu zostanie odcięta w nagraniu.

Tabela 4. screenrecord opcji

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

Odczyt profili ART aplikacji

Od Androida 7.0 (poziom interfejsu API 24) środowisko wykonawcze Androida (ART) zbiera profile wykonania zainstalowanych aplikacji, które są używane do optymalizacji wydajności aplikacji. Przeanalizuj 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 wykonania można pobrać tylko wtedy, gdy masz dostęp do systemu plików na poziomie roota, np. na emulatorze.

Aby uzyskać tekstową formę informacji o profilu, użyj tego polecenia:

adb shell cmd package dump-profiles package

Aby pobrać utworzony plik, użyj tego polecenia:

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

Resetowanie urządzeń testowych

Jeśli testujesz aplikację na wielu urządzeniach testowych, warto zresetować urządzenie między testami, np. aby usunąć dane użytkownika i zresetować środowisko testowe. Możesz przywrócić urządzenie testowe z Androidem 10 (poziom interfejsu API 29) lub nowszym do ustawień fabrycznych za pomocą polecenia powłoki testharness adb, jak pokazano poniżej:

adb shell cmd testharness enable

Podczas przywracania urządzenia za pomocą testharness automatycznie tworzona jest kopia zapasowa klucza RSA, który umożliwia debugowanie na bieżącej stacji roboczej w trwałej lokalizacji. Oznacza to, że po zresetowaniu urządzenia stacja robocza może nadal debugować i wydawać polecenia adb bez ręcznego rejestrowania nowego klucza.

Aby ułatwić i zabezpieczyć testowanie aplikacji, użycie testharness do przywrócenia urządzenia spowoduje też zmianę tych ustawień urządzenia:

• Urządzenie konfiguruje określone ustawienia systemowe, aby nie wyświetlać początkowych kreatorów konfiguracji urządzenia. 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 automatyczną synchronizację kont.
  • Wyłącza automatyczne aktualizacje systemu.
• Inne:
  • Wyłącza wstępnie zainstalowane aplikacje zabezpieczające.

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

sqlite

sqlite3 uruchamia program wiersza poleceń sqlite do sprawdzania baz danych SQLite. Obejmuje polecenia takie jak .dump do drukowania zawartości tabeli i.schema do drukowania SQL CREATE dla istniejącej tabeli. Możesz też wykonywać 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, np. na emulatorze.

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

adb USB backends

Serwer adb może komunikować się ze stosem USB za pomocą 2 interfejsów backendu. Może korzystać z natywnego backendu systemu operacyjnego (Windows, Linux lub macOS) albo z backendu libusb. Niektóre funkcje, takie jak attach, detach i wykrywanie prędkości USB, są dostępne tylko wtedy, gdy używasz backendu libusb.

Możesz wybrać backend za pomocą zmiennej środowiskowej ADB_LIBUSB. Jeśli nie jest ustawiony, adb używa domyślnego backendu. Domyślne działanie różni się w zależności od systemu operacyjnego. Od ADB w wersji 34 domyślnie używany jest backend liubusb na wszystkich systemach operacyjnych z wyjątkiem Windowsa, w którym domyślnie używany jest natywny backend. Jeśli ustawiona jest wartość ADB_LIBUSB, określa ona, czy ma być używany natywny backend, czy libusb. Więcej informacji o zmiennych środowiskowych adb znajdziesz na stronie podręcznika adb.

Backendy mDNS adb

ADB używa protokołu mDNS (multicast DNS) do automatycznego łączenia serwera i urządzeń w celu bezprzewodowego debugowania. Od wersji 37 serwer ADB jest dostarczany z 2 backendami mDNS: libadbmdns i openscreen.

Domyślnym i zalecanym backendem jest libadbmdns. To zachowanie można zmienić za pomocą zmiennej środowiskowej ADB_MDNS_OPENSCREEN (ustawionej na 1 lub 0). Obsługa backendu Openscreen w systemie macOS jest dostępna od wersji ADB 35. Systemy Windows i Linux są obsługiwane od wersji ADB 34.

Tryb seryjny ADB (od wersji ADB 36.0.0)

Tryb seryjny to eksperymentalna funkcja, która umożliwia ADB ciągłe wysyłanie pakietów do urządzenia, nawet zanim urządzenie odpowie na poprzedni pakiet. Znacznie zwiększa to przepustowość ADB podczas przesyłania dużych plików, a także zmniejsza opóźnienia podczas debugowania.

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

• Ustaw zmienną środowiskową ADB_BURST_MODE na 1.
• W Android Studio otwórz ustawienia debugera: Plik (lub Android Studio na macOS) > Ustawienia > Kompilacja, wykonanie, wdrażanie > Debuger i ustaw Tryb seryjny serwera ADB na Włączony.