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, w której możesz uruchamiać różne polecenia na urządzeniu. Jest to program typu klient-serwer, który składa się z 3 komponentów:

• Klient, który wysyła polecenia. Klient działa na komputerze używanym do programowania. 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 przez adb, w tym o tym, jak używać Asystenta połączeń do rozwiązywania typowych problemów, znajdziesz w artykule Uruchamianie aplikacji na urządzeniu.

android [install|run|screen capture|layout]

Jak działa adb

Gdy uruchamiasz klienta adb, najpierw sprawdza on, czy jest już uruchomiony proces serwera adb. 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 podłączony do adb na porcie 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 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 adb klientów, więc możesz sterować dowolnym urządzeniem z dowolnego klienta lub za pomocą 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 systemu 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 (API na poziomie 17) lub nowszym, system wyświetli okno z pytaniem, czy zaakceptować klucz RSA, który umożliwia debugowanie na tym komputerze. Ten mechanizm zabezpieczeń chroni urządzenia użytkowników, ponieważ uniemożliwia wykonywanie debugowania USB i innych poleceń adb, chyba że użytkownik odblokuje urządzenie i potwierdzi okno dialogowe.

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

Nawiązywanie połączenia z urządzeniem przez Wi-Fi

Uwaga: poniższe instrukcje nie dotyczą urządzeń z Wear OS z Androidem 11 (API na poziomie 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ą narzędzia 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 sterowników.

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:

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

• Upewnij się, że na urządzeniu jest zainstalowany Android 11 (API na poziomie 30) lub nowszy w przypadku telefonu albo Android 13 (API na poziomie 33) lub nowszy w przypadku telewizora i Wear OS. Więcej informacji znajdziesz w artykule Sprawdzanie i aktualizowanie wersji Androida.

• Na 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 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 go nie zapomnisz 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 kliknięcie pola wyboru Zawsze zezwalaj w tej sieci sprawia, że sieć staje się zaufaną siecią bezprzewodową do debugowania. Urządzenie zawsze zezwala na debugowanie bezprzewodowe w tej sieci, gdy tylko się z nią połączy.

   

   Rysunek 2. Ustawienie Debugowanie bezprzewodowe na telefonie Google 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 za pomocą kodu parowania i zanotuj adres IP, numer portu i kod parowania wyświetlane na urządzeniu.

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

6. W terminalu stacji roboczej uruchom polecenie 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. Możesz teraz korzystać z urządzenia 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 programisty w Szybkich ustawieniach dla debugowania bezprzewodowego, które znajdziesz w Opcjach programisty > Kafelki programisty w Szybkich ustawieniach.

   

   Rysunek 4. Ustawienie Kafelki programisty w Szybkich ustawieniach 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 Twojej 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 dane wyjściowe są puste, oznacza to, że 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"
     }
   }
             

Sprawdzanie, czy urządzenie obsługuje ADB Wi-Fi 2.0

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

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 dane wyjściowe zawierają wartość mdns_service_version: "2.0" lub wyższą. Jeśli tak nie jest, oznacza to, że na urządzeniu nie ma Androida 17 lub nowszego i nie obsługuje ono ADB Wi-Fi 2.0. Aby zaktualizować system do Androida 17 lub nowszego, sprawdź, czy na urządzeniu nie ma oczekujących aktualizacji systemu. Sprawdzanie i aktualizowanie wersji Androida

Zgłaszanie nowego problemu

Jeśli nadal masz problemy z bezprzewodowym połączeniem 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.
• Dzienniki z adb na stacji roboczej:
  1. Ustaw zmienną środowiskową ADB_TRACE=all.
  2. Uruchom ponownie serwer adb, wpisując 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 Androidzie 10 i starszych wersjach)

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

Uwaga: poniższe 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ż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. Może być konieczne użycie punktu dostępu, którego zapora sieciowa jest prawidłowo skonfigurowana pod kątem 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ą 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:

• Sprawdź, czy host jest nadal połączony 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 te 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 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, ponieważ urządzenie łączy się z adb podczas uruchamiania systemu. 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. Ta informacja jest przydatna, gdy masz podłączonych wiele urządzeń, ponieważ pozwala je odróżnić.

Poniższy przykład pokazuje polecenie devices i jego wynik. 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 uruchomione emulatory nie są widoczne w danych wyjściowych adb devices, mimo że są widoczne na pulpicie. Dzieje się tak, gdy wszystkie z tych warunków są spełnione:

• Serwer adb nie działa.
• Użyj polecenia emulator z opcją -port lub -ports i nieparzystą wartością portu z zakresu 5554–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 on 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.

Aby uniknąć tej sytuacji, możesz pozwolić emulatorowi wybrać własne porty i uruchamiać 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 tej sekwencji poleceń adb devices wyświetla listę urządzeń, ponieważ serwer adb został uruchomiony jako pierwszy.

Aby zobaczyć emulator w danych wyjściowych polecenia 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ć miejsce docelowe:

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 określić.
   1. Jeśli zamierzasz wydać wiele poleceń adb, możesz zamiast tego ustawić zmienną środowiskową $ANDROID_SERIAL, 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 najpierw pobierana jest lista podłączonych urządzeń, a następnie numer seryjny jednego z nich jest używany do zainstalowania helloWorld.apk na tym urządzeniu:

$ 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 wysł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

Możesz użyć adb, aby zainstalować plik APK na emulatorze lub podłączonym urządzeniu za pomocą polecenia install:

adb install path_to_apk

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

Aby zainstalować kilka plików APK, użyj install-multiple. Jest to przydatne, jeśli pobierasz 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ć bezpośrednio polecenia adb, aby zainstalować aplikację na emulatorze lub urządzeniu. Zamiast tego 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 odróżnieniu od 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 nastąpić 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 elementów:

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

Jeśli działa tylko 1 emulator lub podłączone jest tylko 1 urządzenie, polecenie adb jest domyślnie wysyłane do tego urządzenia. Jeśli działa kilka emulatorów lub jest podłączonych kilka 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ć jedno 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 pod adresem toybox --help.

W narzędziach platformy Androida w wersji 23 i nowszych polecenie 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 adb shell setprop key "'two words'" działa, ponieważ powłoka lokalna przyjmuje zewnętrzny poziom cytowania, a urządzenie nadal widzi wewnętrzny poziom cytowania: 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łoce 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 adbbez 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ądzeń (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 dpm jest następująca:

dpm command

Możesz też wydać polecenie menedżera zasad dotyczących urządzeń bezpośrednio z adb bez wchodzenia do powłoki zdalnej:

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 poziomu wiersza poleceń, wpisz:

adb shell screencap /sdcard/screen.png

Oto przykładowa sesja zrzutu ekranu, w której za pomocą powłoki adb wykonano zrzut ekranu, a za pomocą polecenia pull pobrano plik z urządzenia:

$ 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 umożliwia określenie formatu 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 wyświetlacza 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żyć 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 poziomu wiersza poleceń, wpisz:

adb shell screenrecord /sdcard/demo.mp4

Zatrzymaj nagrywanie ekranu, naciskając Control+C. W przeciwnym razie nagrywanie zatrzyma 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 nagraniowej:

$ 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, o którą poprosisz, zachowując współczynnik proporcji wyświetlacza urządzenia. Narzędzie 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 ekranu.
• 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 (interfejs API na poziomie 24) środowisko wykonawcze Androida (ART) zbiera profile wykonania zainstalowanych aplikacji, które są używane do optymalizacji wydajności aplikacji. Sprawdź zebrane profile, aby dowiedzieć się, które metody są często wykonywane, a 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 kilku urządzeniach, warto zresetować urządzenie między testami, np. aby usunąć dane użytkownika i zresetować środowisko testowe. Możesz zresetować urządzenie testowe z Androidem 10 (poziom interfejsu API 29) lub nowszym za pomocą polecenia powłoki testharness adb, jak pokazano poniżej:

adb shell cmd testharness enable

Podczas przywracania urządzenia za pomocą testharness urządzenie automatycznie tworzy kopię zapasową klucza RSA, który umożliwia debugowanie za pomocą 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 powoduje też zmianę tych ustawień urządzenia:

• Urządzenie konfiguruje niektóre ustawienia systemowe, aby nie wyświetlać początkowych kreatorów konfiguracji. 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 wydrukowania zawartości tabeli i .schema do wydrukowania instrukcji SQL CREATE dla istniejącej tabeli. Polecenia SQLite możesz też wykonywać 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 sqlite3dokumentacji wiersza poleceń.

Interfejsy USB ADB

Serwer adb może wchodzić w interakcje ze stosem USB za pomocą 2 backendów. 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. Począwszy od ADB w wersji 34, w przypadku wszystkich systemów operacyjnych z wyjątkiem Windows domyślnie używany jest backend libusb. W systemie Windows domyślnie używany jest natywny backend. Jeśli ustawiono ADB_LIBUSB, określa, czy ma być używany backend natywny 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ń na potrzeby debugowania bezprzewodowego. 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 wysyłanie pakietów do urządzenia, zanim to 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, klikając Plik (lub Android Studio na macOS) > Ustawienia > Kompilacja, wykonanie, wdrażanie > Debuger i ustaw Tryb seryjny serwera ADB na Włączony.