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 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 komponentów:

• Klient, który wysyła polecenia. Klient działa na komputerze, na którym tworzysz aplikacje. Możesz wywołać klienta z poziomu terminala wiersza poleceń, wykonując polecenie adb.
• Demon (adbd), który uruchamia polecenia na urządzeniu. Demon działa w tle jako proces na każdym urządzeniu.
• Serwer zarządzający komunikacją między klientem a demonem. Serwer działa jako proces w tle na komputerze programisty.

adb jest zawarty w pakiecie 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 chcesz pobrać samodzielny pakiet Platform Tools na Androida, pobierz go tutaj.

Informacje o podłączaniu urządzenia do korzystania z adb, w tym o używaniu Asystenta do rozwiązywania typowych problemów, znajdziesz w artykule Uruchanie aplikacji na urządzeniu z sprzętem.

Jak działa adb

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

Uwaga: wszyscy klienci adb używają portu 5037 do komunikacji z serwerem adb.

Następnie serwer tworzy 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. Jeśli serwer znajdzie demona adb (adbd), skonfiguruje połączenie z tym portem.

Każdy emulator używa pary kolejnych portów – parzystej liczby dla połączeń z konsolą i nieparzystej liczby dla połączeń adb. Na 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 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ć do nich dostęp za pomocą poleceń adb. Ponieważ serwer zarządza połączeniami z urządzeniami i obsługuje polecenia z wielu klientów adb, możesz sterować dowolnym urządzeniem z dowolnego klienta lub ze skryptu.

Włączanie debugowania adb na urządzeniu

Aby używać adb z urządzeniem połączonym przez USB, musisz włączyć debugowanie USB w ustawieniach systemowych urządzenia w sekcji Opcje dla deweloperów. W Androidzie 4.2 (interfejs API 17) i nowszych ekran Opcje programisty jest domyślnie ukryty. Aby go wyświetlić, włącz Opcje programisty.

Możesz teraz połączyć urządzenie przez USB. Aby sprawdzić, czy urządzenie jest połączone, uruchom adb devices z katalogu android_sdk/platform-tools/. Jeśli urządzenie jest połączone, zobaczysz jego nazwę 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 zapytaniem, czy chcesz 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, chyba że użytkownik odblokuje urządzenie i potwierdzi to w oknie dialogowym.

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

Łączenie 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 po debugowaniu aplikacji na Wear OS.

Android 11 (poziom interfejsu API 30) i nowsze wersje obsługują wdrażanie i debugowanie aplikacji bezprzewodowo z stanowiska roboczego 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. 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:

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

• Upewnij się, że masz urządzenie z Androidem 11 (poziom API 30) lub nowszym (w przypadku telefonu) albo Androidem 13 (poziom API 33) lub nowszym (w przypadku telewizora i Wear OS). 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ć tutaj.

• 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 połączyć się z urządzeniem:

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

2. Otwórz Android Studio i w menu konfiguracji uruchomienia wybierz Pair Devices Using Wi-Fi (Parowanie urządzeń za pomocą Wi-Fi).

   

   Rysunek 1. Menu konfiguracji uruchomień.

   Pojawi się okno Sparuj urządzenia przez Wi-Fi, jak pokazano na rysunku 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 przez Wi-Fi 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 przy użyciu kodu QR i zeskanuj kod QR uzyskany z wyskakującego okienka Sparuj urządzenia przez Wi-Fi, jak pokazano na rysunku 2.

   2. Aby sparować urządzenie za pomocą 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 Sparuj urządzenia przez Wi-Fi, kliknij Sparuj i wpisz 6-cyfrowy kod widoczny 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 usunąć obecne urządzenie z komputera, na urządzeniu przejdź do Połącz bezprzewodowo z debugowaniem. Kliknij nazwę stacji roboczej w sekcji Skojarzone urządzenia i wybierz Zapomnij.

5. Jeśli chcesz szybko włączać i wyłączać debugowanie bezprzewodowe, możesz skorzystać z kafelków szybkich ustawień dla programisty dotyczących debugowania bezprzewodowego, które znajdziesz w sekcji Opcje programisty > Kafelki szybkich ustawień dla programisty.

   

   Rysunek 5. Ustawienie Kafelki szybkich ustawień dla programisty 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 opcje programisty na urządzeniu, jak opisano wcześniej.

2. Włącz bezprzewodowe debugowanie na urządzeniu, zgodnie z opisem powyżej.

3. Na 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 adresu IP i numeru portu z powyższego.

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

   

   Rysunek 6. Pojawi się komunikat informujący o sparowaniu urządzenia.

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:

• Nie można połączyć się z Wi-Fi: bezpieczne sieci Wi-Fi, takie jak sieci Wi-Fi firmowe, mogą blokować połączenia p2p i nie pozwalać na połączenie przez Wi-Fi. Spróbuj połączyć się za pomocą kabla lub innej sieci Wi-Fi (niefirmowej). 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, ponownie połącz się 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 proces jest również dostępny w Androidzie 11 (i wyższych), ale wymaga *wstępnego* połączenia przez fizyczny kabel USB.

Uwaga: te instrukcje nie dotyczą urządzeń Wear z Androidem 10 (poziom interfejsu API 29) lub niższym. 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 (poziom interfejsu API 29) lub starszym, wykonaj te wstępne czynności przez USB:

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

Uwaga: pamiętaj, że 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. Ustaw 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 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, wykonując ponownie krok adb connect.
• Jeśli to nie zadziała, zresetuj hosta adb:

  adb kill-server
  

  Następnie zacznij od początku.

Zapytanie o urządzenia

Zanim wydasz polecenia adb, warto sprawdzić, które instancje urządzenia 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, ponieważ urządzenie łączy się z adb, gdy system jest jeszcze uruchamiany. Po uruchomieniu jest to normalny stan działania urządzenia.
  • no device: brak podłączonego urządzenia.
• 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ć.

Poniższy przykład przedstawia polecenie devices i jego dane wyjściowe. Są uruchomione 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

Nie ma emulatora na liście

Polecenie adb devices ma sekwencję poleceń, która powoduje, że uruchomione emulatory nie pojawiają się w wyjściu adb devices, mimo że są widoczne na pulpicie. 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 przez Ciebie port o nieparzystej liczbie nie jest zajęty, więc można nawiązać połączenie z portem o określonym numerze portu. Jeśli port jest zajęty, emulator przełączy się na inny port, który spełnia wymagania podane w punkcie 2.
• Serwer adb uruchamiasz po uruchomieniu emulatora.

Aby uniknąć takiej sytuacji, możesz pozwolić emulatorowi na wybór własnych portów i uruchomienie nie więcej niż 16 emulatorów naraz. Innym sposobem jest uruchamianie serwera adb zawsze przed użyciem polecenia emulator, zgodnie z poniższymi przykładami.

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

Zatrzymaj serwer adb i wpisz podane niżej polecenia w podanej kolejności. W przypadku nazwy AVD podaj prawidłową nazwę AVD z Twojego 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 poniższej sekwencji poleceń adb devices wyświetla listę urządzeń, ponieważ najpierw uruchomiono 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 wiersza poleceń emulatora znajdziesz w artykule Opcje uruchamiania w wierszu poleceń.

Wysyłanie poleceń do konkretnego urządzenia

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

1. Aby uzyskać numer seryjny celu, użyj polecenia devices.
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 właściwości -s, jak i $ANDROID_SERIAL, pierwszeństwo ma ta pierwsza.-s$ANDROID_SERIAL

W tym przykładzie uzyskuje się listę podłączonych urządzeń, a następnie numer seryjny jednego z nich, aby zainstalować 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ślenia urządzenia docelowego, a dostępne są 2 urządzenia, adb wyświetli błąd „adb: more than one device/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 masz 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

Aby zainstalować plik APK na emulatorze lub połączonym urządzeniu, użyj polecenia adb install:

adb install path_to_apk

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

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

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

Uwaga: jeśli używasz Android Studio, nie musisz bezpośrednio uruchamiać narzędzia adb, aby zainstalować aplikację na emulatorze lub urządzeniu. Zamiast tego Android Studio samodzielnie zapakuje i zainstaluje aplikację.

Skonfiguruj przekierowanie portów

Aby skonfigurować dowolne przekierowanie portów, które przekierowuje żądania na określonym porcie hosta na inny port na urządzeniu, użyj polecenia forward. Poniżej znajduje się przykład konfigurowania przekierowania hosta z portu 6100 na port 7100 urządzenia:

adb forward tcp:6100 tcp:7100

W tym przykładzie konfigurujemy przekierowanie portu hosta 6100 na lokalny:logd:

adb forward tcp:6100 local:logd

Może to być przydatne, jeśli chcesz określić, co jest wysyłane do danego portu na urządzeniu. Wszystkie otrzymane dane zostaną zapisane w demonie dziennikowania systemu i wyświetlone w dziennikach 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 wraz z podkatalogami z urządzenia:

adb pull remote local

Aby skopiować plik lub katalog wraz z podkatalogami na urządzenie, wykonaj te czynności:

adb push local remote

Zastąp local i remote ścieżkami do plików docelowych lub katalogu docelowego na komputerze programisty (lokalnie) i na urządzeniu (zdalnie). Na przykład:

adb push myfile.txt /sdcard/myfile.txt

Zatrzymaj serwer 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.

Wydawanie poleceń adb

Wyślij polecenia adb w wierszu poleceń na komputerze programistycznym lub w skrypcie za pomocą:

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

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

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

adb --help

Wydawanie poleceń powłoki

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

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

Aby uruchomić interaktywny powłokę na urządzeniu, użyj polecenia shell w takiej postaci:

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

Aby wyjść z interaktywnej powłoki, 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

Większość poleceń ma pomoc dostępną za pomocą argumentu --help. Wiele poleceń powłoki jest udostępnianych przez toybox. Ogólną pomoc dotyczącą wszystkich poleceń ze skrzynią z zabawkami można uzyskać pod adresem toybox --help.

W narzędziach platformy Android w wersji 23 lub nowszej polecenie adb obsługuje argumenty w taki sam sposób 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ę też interpretacja wszystkich 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, użyj cudzysłowów 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 cudzysłowów, a urządzenie nadal widzi wewnętrzny poziom cudzysłowów: setprop key 'two words'. Zmiana znaczenia również jest możliwa, ale podwójne cytowanie jest zwykle łatwiejsze.

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

Menedżer aktywności połączeń

W powłoce adb 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, przymusowe zatrzymywanie procesu, rozgłaszanie intencji czy modyfikowanie właściwości ekranu urządzenia.

W powłoce składnia am ma postać:

am command

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

Zadzwoń do menedżera pakietów (pm)

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

W powłoce składnia pm wygląda tak:

pm command

Możesz też wydać polecenie menedżera pakietów bezpośrednio z poziomu adb, bez uruchamiania powłoki zdalnej. Na 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:

dpm command

Możesz też wydać polecenie menedżera zasad urządzenia bezpośrednio z poziomu adb, bez uruchamiania powłoki zdalnej:

adb shell dpm command

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

Zrób zrzut ekranu

Komenda screencap to narzędzie powłoki do robienia zrzutów ekranu z urządzenia.

W powłoce składnia screencap wygląda tak:

screencap filename

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

adb shell screencap /sdcard/screen.png

Oto przykład sesji robienia zrzutów ekranu, w której użyto powłoki adb do zrobienia zrzutu ekranu i polecenia pull do 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 do nagrywania ekranu urządzeń z Androidem w wersji 4.4 (poziom interfejsu API 19) lub nowszej. Narzędzie rejestruje aktywność związaną z ekranem w pliku MPEG-4. Możesz go użyć 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 nagranie 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ł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 współczynnik proporcji wyświetlacza urządzenia. Narzędzie domyślnie nagrywa w domyślnej rozdzielczości i orientacji ekranu. Maksymalna długość nagrania to 3 minuty.

Ograniczenia narzędzia screenrecord:

• Dźwięk nie jest nagrywany wraz z plikiem wideo.
• Nagrywanie filmów jest niedostępne na urządzeniach z Wear OS.
• Niektóre urządzenia mogą nie być w stanie nagrywać 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 ekran obraca się podczas nagrywania, część ekranu może być przycięta na nagraniu.

Tabela 4. screenrecord opcji

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

Odczytywanie profili ART w aplikacjach

Od Androida 7.0 (poziom interfejsu API 24) środowisko uruchomieniowe Androida (ART) zbiera profile wykonywania zainstalowanych aplikacji, które są używane do optymalizacji ich wydajności. 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 z profilu w postaci tekstu, 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 zresetować urządzenie między 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 za pomocą testharness urządzenie automatycznie tworzy kopię zapasową klucza RSA, który umożliwia debugowanie na bieżącej stacji roboczej w stałej lokalizacji. Oznacza to, że po zresetowaniu urządzenia stacja robocza może nadal debugować i wysyłać do urządzenia polecenia adb bez ręcznego rejestrowania nowego klucza.

Aby ułatwić i ubezpieczyć dalsze testowanie aplikacji, przy użyciu opcji testharness do przywracania urządzenia zmieniamy też te ustawienia urządzenia:

• Urządzenie konfiguruje określone ustawienia systemowe, aby nie pojawiały się początkowe kreatory 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 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 polecenia ActivityManager.isRunningInUserTestHarness().

sqlite

sqlite3 uruchamia program wiersza poleceń sqlite do sprawdzania baz danych SQLite. Zawiera ona polecenia takie jak .dump, które służy do drukowania zawartości tabeli, oraz .schema, które służy do drukowania instrukcji SQL CREATE w przypadku istniejącej tabeli. Polecenia SQLite możesz też wykonywać z poziomu wiersza poleceń:

$ 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 dotyczącej wiersza poleceń sqlite3.

adb USB backend

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 USB, są dostępne tylko w przypadku korzystania z back-endu libusb.

Możesz wybrać backend za pomocą zmiennej środowiskowej ADB_LIBUSB. Jeśli nie zostanie ustawiony, adb użyje domyślnego backendu. Domyślne zachowanie zależy od systemu operacyjnego. Od wersji ADB 34 domyślnie używany jest backend liubusb we wszystkich systemach operacyjnych, z wyjątkiem systemu Windows, w którym domyślnie używany jest natywny backend. Jeśli parametr ADB_LIBUSB jest ustawiony, określa, czy ma być używany natywny backend czy libusb. Więcej informacji o zmiennych środowiskowych adb znajdziesz w instrukcji obsługi adb.

Backendy adb mDNS

ADB może używać protokołu multicast DNS do automatycznego łączenia serwera i urządzeń. Serwer ADB jest dostarczany z 2 backendami: Bonjour (mdnsResponder firmy Apple) i Openscreen.

Backend Bonjour wymaga uruchomienia demona na maszynie hosta. W systemie macOS wbudowany demon Apple jest zawsze uruchomiony, ale w systemach Windows i Linux użytkownik musi upewnić się, że demon mdnsd jest uruchomiony. Jeśli polecenie adb mdns check zwróci błąd, prawdopodobnie ADB używa backendu Bonjour, ale nie działa demon Bonjour.

Backend Openscreen nie wymaga demona do działania na komputerze. Obsługa backendu Openscreen na komputerach Mac jest dostępna od wersji ADB 35. Systemy Windows i Linux są obsługiwane od wersji ADB 34.

Domyślnie ADB używa 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.