Android Debug Bridge (adb)

Android Debug Bridge (adb) to wszechstronne narzędzie wiersza poleceń, które umożliwia komunikację z urządzeniem. Polecenie adb umożliwia wykonywanie różnych działań na urządzeniu, takich jak instalowanie i debugowanie aplikacji. adb zapewnia dostęp do powłoki Unix, której możesz używać do wykonywania 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 Twoim komputerze programistycznym. Możesz wywołać klienta z poziomu terminala wiersza poleceń, wykonując polecenie adb.
• Demon (adbd), który wykonuje polecenia na urządzeniu. Demon działa w tle jako proces 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 programisty.

adb jest zawarty w pakiecie narzędzi platformy Android SDK. Pobierz ten pakiet za pomocą Menedżera pakietu SDK, który zainstaluje go w katalogu android_sdk/platform-tools/. Jeśli chcesz pobrać samodzielny pakiet Platform Tools w ramach Android SDK, pobierz go tutaj.

Informacje o podłączaniu urządzenia do korzystania z adb, w tym o używaniu Asystenta połączeń do rozwiązywania typowych problemów, znajdziesz w artykule Uruchamianie aplikacji na urządzeniu z oprogramowaniem.

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ów adb.

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

Następnie serwer łączy się ze wszystkimi uruchomionymi urządzeniami. Lokalizuje je, skanując porty o nieparzystych numerach w zakresie od 5555 do 5585, który jest używany przez pierwsze 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 – port o parzystej liczbie do połączeń z konsolą i port o nieparzystej liczbie do połączeń z 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 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 przetwarza komendy z różnych 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 podłączyć urządzenie kablem 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 dialogowe z pytaniem, 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, dopóki nie odblokujesz urządzenia i nie potwierdzisz w oknie dialogowym.

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

Łączenie z urządzeniem przez Wi-Fi

Uwaga: te instrukcje nie dotyczą urządzeń Wear 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 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 musisz rozwiązywać typowych problemów z połączeniem USB, takich jak instalacja sterownika.

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 z 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 z stanowiskiem roboczym 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. Okno z prośbą o sparowanie urządzeń za pomocą kodu QR lub kodu parowania.

3. Na urządzeniu kliknij Debugowanie przez Wi-Fi i sparuj urządzenie:

   

   Rysunek 3. Zrzut ekranu z ustawienia 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 przy użyciu kodu parowania, w wyskakującym okienku Sparuj urządzenia przez Wi-Fi wybierz Sparuj urządzenie przy użyciu kodu parowania. Na urządzeniu wybierz Sparuj za pomocą kodu parowania i zapisz podany 6-cyfrowy kod. Gdy Twoje 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 wpisywania 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 Kafle szybkich ustawień dla programisty pozwala szybko włączać i wyłączać debugowanie bezprzewodowe.

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

Aby 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źć adres IP, numer portu i kod parowania, wybierz Sparuj urządzenie za pomocą kodu parowania. Zapisz adres IP, numer portu i kod parowania wyświetlony na urządzeniu.

5. W terminalu na stacji roboczej uruchom adb pair ipaddr:port. Użyj adresu IP i numeru portu z sekcji powyżej.

6. Gdy pojawi się prośba, wpisz kod parowania widoczny 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 połączeniem bezprzewodowym z urządzeniem, wykonaj te czynności, aby je rozwiązać.

Sprawdź, czy stanowisko robocze 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.

Sprawdzanie innych znanych problemów

Poniżej znajdziesz listę znanych problemów z debugowaniem bezprzewodowym (za pomocą adb lub Android Studio) oraz sposoby ich rozwiązywania:

• Nie można połączyć się przez 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). Inną opcją jest połączenie bezprzewodowe za pomocą adb connect ip:port przez tcp/ip (po początkowym połączeniu przez USB), jeśli korzystanie z sieci niefirmowej jest możliwe.

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

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

Połączenie bezprzewodowe z urządzeniem po początkowym połączeniu przez USB (opcja dostępna tylko 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ą jego adresu IP:

   adb connect device_ip_address:5555
   

7. Sprawdź, czy komputer hosta 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 adb.

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

• Upewnij się, że gospodarz 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 wyświetla informacje o stanie każdego urządzenia:

• Numer seryjny: adb tworzy ciąg znaków, aby jednoznacznie zidentyfikować urządzenie za pomocą jego numeru portu. Oto przykład numeru seryjnego: emulator-5554
• Stan:urządzenie może mieć jeden z tych stanów połączenia:
  • 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 uruchamiany. Po uruchomieniu jest to normalny stan operacyjny urządzenia.
  • no device: brak podłączonego urządzenia.
• Opis: jeśli uwzględnisz opcję -l, polecenie devices powie Ci, jakie to urządzenie. Te informacje są przydatne, gdy masz podłączonych kilka urządzeń, ponieważ możesz je od siebie odróżnić.

Poniższy przykład przedstawia polecenie devices i jego dane wyjściowe. Urządzenia są włączone. Pierwsze 2 wiersze na liście to emulatory, a trzeci 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

Emulator nie jest wymieniony

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 wszystkie te warunki są spełnione:

• Serwer adb nie działa.
• Użyj polecenia emulator z opcją -port lub -ports z nieparzystą wartością portu z zakresu 5554–5584.
• Wybrany przez Ciebie port o nieparzystej liczbie nie jest zajęty, więc połączenie portu może być utworzone na określonym numerze portu. Jeśli port jest zajęty, emulator przełączy się na inny port, który spełnia wymagania opisane w punkcie 2.
• Po uruchomieniu emulatora uruchom serwer adb.

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 zawsze uruchamianie serwera adb przed użyciem polecenia emulator, jak pokazano w następujących przykładach.

Przykład 1: w tej 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 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ż najpierw uruchomiono serwer adb.

Aby zobaczyć emulator w danych wyjściowych adb devices, zatrzymaj serwer adb, a następnie uruchom go ponownie po wydaniu polecenia emulator, ale przed wydaniem polecenia adb devices:

$ 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 działa kilka urządzeń, musisz określić urządzenie docelowe, gdy wydajesz polecenie adb. Aby określić wartość docelową, wykonaj te czynności:

1. Aby uzyskać numer seryjny celu, użyj polecenia devices.
2. Gdy już znasz numer seryjny, użyj opcji -s z poleceniami adb, aby go podać.
   1. Jeśli zamierzasz wydawać dużo 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 jest więcej niż 1 urządzenie, adb wyświetli błąd „adb: more than one device/emulator”.

Jeśli masz kilka urządzeń, ale tylko jedno z nich jest emulatorem, użyj opcji -e, aby wysyłać polecenia do emulatora. Jeśli masz kilka 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 artykule -t.

Aby zainstalować wiele plików APK, użyj polecenia install-multiple. Jest to przydatne, jeśli pobierzesz z Konsoli Play wszystkie pliki APK 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ć 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. W tym przykładzie konfigurujemy przekierowanie portu hosta 6100 na port urządzenia 7100:

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 na urządzenie i z niego

Aby kopiować pliki na urządzenie lub z niego, użyj poleceń pull i push. W przeciwieństwie do polecenia install, które kopiuje tylko plik APK 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 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). Przykład:

adb push myfile.txt /sdcard/myfile.txt

Zatrzymaj serwer adb

W niektórych przypadkach konieczne może być zakończenie procesu serwera adb, a następnie jego ponowne uruchomienie. Może się tak zdarzyć, jeśli adb nie reaguje 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 udostępnia większość zwykłych narzędzi wiersza poleceń Unix. Aby wyświetlić listę dostępnych narzędzi, uruchom to polecenie:

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ólne informacje dotyczące wszystkich poleceń toybox znajdziesz na stronie toybox --help.

W narzędziach platformy Android 23 i nowszych argumenty są obsługiwane w ten sam sposób, w jaki robi to polecenie ssh(1).adb Ta zmiana rozwiązała wiele problemów z wstrzyknięciem poleceń i umożliwia 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 teraz błędem, ponieważ cudzysłówy są połykane przez lokalną powłokę, a urządzenie widzi 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'. Użycie znaku ucieczki jest również opcją, ale zwykle łatwiej jest użyć dwukrotnego cudzysłowu.

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:

am command

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

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 jest następująca:

pm command

Możesz też wydać polecenie menedżera pakietów bezpośrednio z poziomu adb, bez uruchamiania powłoki zdalnej. 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ć sobie tworzenie i testowanie aplikacji do zarządzania urządzeniami, wydawaj polecenia narzędziu Device Policy Manager (dpm). Za pomocą tego narzędzia możesz kontrolować aktywną aplikację administratora lub zmienić dane stanu 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 w powłoce do robienia zrzutów ekranu z 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ład sesji robienia zrzutów 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

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ść na ekranie 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ł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 bitów, zachowując współczynnik proporcji ekranu 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.
• Obrót ekranu podczas nagrywania nie jest obsługiwany. 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. Przejrzyj 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 root do systemu plików, na przykład na emulatorze.

Aby wygenerować informacje z profilu w postaci tekstu, użyj tego polecenia:

adb shell cmd package dump-profiles package

Aby pobrać wygenerowany plik, użyj:

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, aby na przykład usunąć dane użytkownika i zresetować środowisko testowe. Urządzenie testowe z Androidem 10 (poziom interfejsu API 29) lub nowszym możesz zresetować 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 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 niego 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 niektóre 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 roota do systemu plików, np. na emulatorze.

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

adb USB backend

Serwer adb może współpracować z kompletem USB za pomocą dwóch backendów. Może on używać natywnego backendu systemu operacyjnego (Windows, Linux lub macOS) lub 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.

adb mDNS backend

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 na maszynie. 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 (ustaw ją na 1 lub 0). Więcej informacji znajdziesz w podręczniku ADB.

tryb burst adb (od wersji ADB 36.0.0),

Tryb serii to funkcja eksperymentalna, która umożliwia ADB ciągłe wysyłanie pakietów do urządzenia, nawet jeśli nie odpowiedziało ono na poprzedni pakiet. To znacznie zwiększa przepustowość ADB podczas przesyłania dużych plików, a także zmniejsza opóźnienia podczas debugowania.

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

• Ustaw zmienną środowiskową ADB_DELAYED_ACK na 1.
• W Android Studio otwórz ustawienia debugera na stronie Plik (lub Android Studio na komputerze Mac) > Ustawienia > Kompilacja, wykonanie, wdrożenie > Debuger i ustaw Tryb burst serwera ADB na Włączony.