Android Debug Bridge (adb)

Android Debug Bridge (adb) to uniwersalne narzędzie wiersza poleceń, które umożliwia komunikację z urządzeniami. 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 uniksowej, której można używać do uruchamiania różnych poleceń na urządzeniu. Na program klient-serwer składają się 3 elementy:

• Klient, który wysyła polecenia. Klient jest uruchamiany na Twoim komputerze do programowania. Możesz wywołać klienta z terminala wiersza poleceń, uruchamiając polecenie adb.
• Demon (adbd), który uruchamia polecenia na urządzeniu. Demon działa w tle na każdym urządzeniu.
• Serwer – zarządza komunikacją między klientem a demonem. Serwer działa w tle na komputerze programistycznym.

adb jest częścią pakietu Android SDK Platform Tools. Pobierz ten pakiet za pomocą Menedżera SDK, który instaluje go pod adresem android_sdk/platform-tools/. Jeśli potrzebujesz samodzielnego pakietu Android SDK Platform Tools, pobierz go tutaj.

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

Jak działa narzędzie adb

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

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

Następnie serwer konfiguruje połączenia ze wszystkimi działającymi urządzeniami. Lokalizuje emulatory, skanując porty o nieparzystych numerach w zakresie od 5555 do 5585, czyli zakres używany przez pierwszych 16 emulatorów. W miejscu, w którym serwer znajduje demona adb (adbd), konfiguruje połączenie z tym portem.

Każdy emulator używa 2 portów sekwencyjnych – numeru parzystego do połączeń w konsoli i portu o nieparzystych numerach na potrzeby połączeń adb. Na przykład:

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

Jak pokazano, emulator połączony z portem 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 poziomu dowolnego klienta lub skryptu.

Włącz debugowanie adb na urządzeniu

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

Możesz teraz podłą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: gdy podłączysz urządzenie z Androidem 4.2.2 (poziom interfejsu API 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ż umożliwia wykonywanie debugowania USB ani innych poleceń adb przed odblokowaniem urządzenia i potwierdzeniem okna dialogowego.

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

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

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

Android 11 (poziom interfejsu API 30) i nowsze obsługują bezprzewodowe wdrażanie i debugowanie aplikacji na stacji roboczej za pomocą Android Debug Bridge (adb). Na przykład aplikację z możliwością debugowania możesz wdrożyć 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.

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 (poziom interfejsu API 30) lub nowszy w przypadku telefonu albo Android 13 (poziom interfejsu API 33) lub nowszy w przypadku telewizorów i Wear OS. Więcej informacji znajdziesz w artykule Sprawdzanie i aktualizowanie wersji Androida.

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

• Na stacji roboczej zaktualizuj SDK Platform Platform Tools do najnowszej wersji.

Aby skorzystać z debugowania bezprzewodowego, sparuj urządzenie ze stacją roboczą, używając kodu QR lub kodu parowania. Stacja robocza i urządzenie muszą być połączone z tą samą siecią bezprzewodową. Aby połączyć się z urządzeniem, wykonaj te czynności:

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

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

   

   Rysunek 1. Menu uruchamiania konfiguracji.

   Pojawi się okno Parowanie urządzeń przez Wi-Fi, jak widać na ilustracji 2.

   

   Rysunek 2. Wyskakujące okienko do sparowania urządzeń przy użyciu kodu QR lub kodu parowania.

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

   

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

   1. Aby sparować urządzenie z kodem QR, wybierz Sparuj urządzenie z kodem QR i zeskanuj kod QR otrzymany w wyskakującym okienku Sparuj urządzenia przez Wi-Fi widocznym na ilustracji 2.

   2. Aby sparować urządzenie z kodem parowania, wybierz Sparuj urządzenie za pomocą kodu parowania w wyskakującym okienku Parowanie urządzeń przez Wi-Fi. Na urządzeniu wybierz Sparuj za pomocą kodu parowania i zanotuj otrzymany 6-cyfrowy kod. Gdy urządzenie pojawi się w oknie Sparuj urządzenia przez Wi-Fi, możesz wybrać Sparuj i wpisać 6-cyfrowy kod wyświetlony na urządzeniu.

      

      Rysunek 4. Przykład 6-cyfrowego kodu.

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

   Aby sparować inne urządzenie lub zapomnieć bieżące urządzenie na stacji roboczej, otwórz na urządzeniu Debugowanie bezprzewodowe. Kliknij nazwę stacji roboczej w sekcji Sparowane urządzenia i wybierz Zapomnij.

5. Jeśli chcesz szybko włączyć lub wyłączyć debugowanie bezprzewodowe, możesz użyć kafelków dla programistów Szybkich ustawień do Debugowania bezprzewodowego. Znajdziesz je w sekcji Opcje programisty > kafelki dla programistów Szybkich ustawień.

   

   Rysunek 5. Ustawienie kafelki szybkich ustawień dla programisty pozwala szybko włączać i wyłączać debugowanie bezprzewodowe.

Połączenie Wi-Fi przy użyciu wiersza poleceń

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

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

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

3. Na 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świetlane na urządzeniu.

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

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

   

   Rysunek 6. Komunikat oznacza, że urządzenie zostało sparowane.

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

Jeśli masz problemy z bezprzewodowym połączeniem się z urządzeniem, wypróbuj te rozwiązania.

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 znajduje się lista znanych problemów z debugowaniem bezprzewodowym (z Adb lub Android Studio) oraz ich rozwiązywaniem:

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

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

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

Łączyć się bezprzewodowo z urządzeniem po pierwszym połączeniu USB (opcja dostępna tylko w Androidzie 10 i starszych).

Uwaga: ten przepływ pracy dotyczy również Androida w wersji 11 (i nowszych), z tym że wymaga on też *początkowego* połączenia przez fizyczne połączenie 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 dotyczącym 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 niższym, wykonaj te czynności przez USB:

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

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

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 możesz sprawdzić w sekcji Ustawienia > Informacje o tablecie (lub Informacje o telefonie) > Stan > Adres IP.
6. Połącz się z urządzeniem, korzystając z jego adresu IP:

   adb connect device_ip_address:5555
   

7. Sprawdź, czy komputer będący hostem jest połączony z urządzeniem docelowym:

   $ adb devices
   List of devices attached
   device_ip_address:5555 device
   

Twoje urządzenie jest teraz połączone z siecią 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.
• Ponownie połącz się, wykonując krok adb connect jeszcze raz.
• Jeśli to nie pomoże, zresetuj hosta adb:

  adb kill-server
  

  Potem zacznij od początku.

Zapytanie dotyczące urządzeń

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

  adb devices -l
  

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

• Numer seryjny: adb tworzy ciąg znaków jednoznacznie identyfikujący urządzenie na podstawie numeru portu. Oto przykładowy numer seryjny: emulator-5554
• Stan: stan połączenia urządzenia może być jeden z tych:
  • offline: urządzenie nie jest połączone z adb lub nie odpowiada.
  • device: urządzenie jest połączone z serwerem adb. Ten stan nie oznacza, że system Android został w pełni rozruchowy i działa normalnie, ponieważ urządzenie łączy się z adb, gdy system nadal się uruchamia. Po uruchomieniu jest to normalny stan działania urządzenia.
  • no device: nie ma połączonych urządzeń.
• Opis: jeśli dodasz opcję -l, polecenie devices pokaże, jakie jest urządzenie. Te informacje są przydatne, gdy masz podłączonych wiele urządzeń, aby móc je odróżnić.

Poniżej znajdziesz przykład polecenia devices i jego danych wyjściowych. Są uruchomione 3 urządzenia. Pierwsze 2 wiersze 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 zawiera sekwencję poleceń zapisywanych narożnikami, co powoduje, że uruchomione emulatory nie wyświetlają się w danych wyjściowych adb devices, mimo że emulatory są widoczne na komputerze. Dzieje się tak, gdy są spełnione wszystkie te warunki:

• Serwer adb nie jest uruchomiony.
• Użyj polecenia emulator z opcją -port lub -ports z portem o nieparzystej liczbie numerów z zakresu od 5554 do 5584.
• Wybrany port o nieparzystych numerach nie jest zajęty, więc można je nawiązać na określonym porcie. Jeśli jest on zajęty, emulator przełącza się na inny port, który spełnia wymagania punktu 2.
• Serwer adb uruchamia się po uruchomieniu emulatora.

Jednym ze sposobów uniknięcia takiej sytuacji jest zezwolenie emulatorowi na wybór własnych portów i uruchamianie maksymalnie 16 emulatorów jednocześnie. Innym sposobem jest uruchomienie serwera adb przed użyciem polecenia emulator, jak wyjaśniono w poniższych przykładach.

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

Zatrzymaj serwer adb i wpisz następujące polecenia w wyświetlonej kolejności. Jako nazwę AVD podaj prawidłową nazwę AVD z Twojego systemu. Aby uzyskać listę nazw AVD, wpisz emulator -list-avds. Polecenie emulator jest w katalogu android_sdk/tools.

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

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

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

Aby wyświetlić 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 o opcjach uruchamiania wiersza poleceń.

Wysyłanie poleceń na konkretne urządzenie

Jeśli działa wiele urządzeń, podczas uruchamiania polecenia adb musisz podać urządzenie docelowe. Aby określić środowisko docelowe, wykonaj te czynności:

1. Aby uzyskać numer seryjny środowiska docelowego, użyj polecenia devices.
2. Gdy uzyskasz numer seryjny, użyj opcji -s za pomocą poleceń adb, aby podać go.
   1. Jeśli zamierzasz uruchomić 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, -s zastępuje $ANDROID_SERIAL.

W poniższym przykładzie odczytywana jest lista podłączonych urządzeń, a następnie numer seryjny jednego z urządzeń służy do zainstalowania na nim helloWorld.apk:

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

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

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

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

Instalowanie aplikacji

Za pomocą polecenia adb możesz zainstalować pakiet APK w emulatorze lub połączonym urządzeniu za pomocą polecenia install:

adb install path_to_apk

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

Aby zainstalować wiele plików APK, użyj aplikacji install-multiple. Przydaje się to, gdy z Konsoli Play pobierasz wszystkie pliki APK dla konkretnego urządzenia i chcesz je zainstalować w emulatorze lub urządzeniu fizycznym.

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

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

Skonfiguruj przekierowanie portów

Za pomocą polecenia forward możesz skonfigurować przekierowanie dowolnych portów, które przekazuje żądania z określonego portu hosta do innego portu w urządzeniu. Ten przykład pozwala skonfigurować przekierowanie portu hosta 6100 na port urządzenia 7100:

adb forward tcp:6100 tcp:7100

Ten przykład pokazuje, jak skonfigurować przekierowanie portu hosta 6100 na local:logd:

adb forward tcp:6100 local:logd

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

Kopiowanie plików na urządzenie i z niego

Aby kopiować pliki na urządzenie i z niego, użyj poleceń pull i push. 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 katalogu docelowego na komputerze programisty (lokalnym) i na urządzeniu (zdalnie). Na przykład:

adb push myfile.txt /sdcard/myfile.txt

Zatrzymaj serwer adb

W niektórych przypadkach musisz zakończyć proces serwera adb, a następnie uruchomić go ponownie, aby rozwiązać problem. Może tak być 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, uruchamiając dowolne inne polecenie adb.

Wydawanie poleceń adb

Polecenia adb możesz wysłać z wiersza poleceń na komputerze programisty lub ze skryptu, korzystając z tych metod:

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

Jeśli działa tylko 1 emulator lub jest podłączone tylko 1 urządzenie, polecenie adb jest domyślnie wysyłane na to urządzenie. Jeśli działa wiele emulatorów lub dołączonych jest kilka urządzeń, użyj opcji -d, -e lub -s, aby określić urządzenie docelowe, na które 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 dla urządzeń za pomocą adb lub uruchomić interaktywną powłokę. Aby wykonać jedno polecenie, użyj polecenia shell w ten sposób:

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

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

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

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

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

adb shell ls /system/bin

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

W narzędziach platformy Android 23 i nowszych 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żliwia bezpieczne wykonywanie poleceń zawierających metaznaki powłoki, np. adb install Let\'sGo.apk. Ta zmiana oznacza, że zmieniła się również interpretacja poleceń zawierających metaznaki powłoki.

Na przykład błąd adb shell setprop key 'value' jest teraz błędem, ponieważ pojedynczy cudzysłów (') jest pochłaniany przez powłokę lokalną, a urządzenie widzi adb shell setprop key value. Aby polecenie działało, zacytuj 2 razy: raz dla lokalnej powłoki i raz dla powłoki zdalnej, tak jak w przypadku ssh(1). Przykład: adb shell setprop key 'value' .

Zobacz też narzędzie wiersza poleceń Logcat, które przydaje się do monitorowania logu systemowego.

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

W powłoce adb możesz wydawać polecenia w narzędziu Menedżer aktywności (am), aby wykonywać różne działania systemowe, takie jak uruchamianie działania, wymuszanie zatrzymania procesu, przesyłanie intencji czy modyfikowanie właściwości ekranu urządzenia.

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

am command

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

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

Tabela 1. Dostępne polecenia w Menedżerze aktywności

Specyfikacja argumentów intencji

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

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

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

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

pm command

Polecenie menedżera pakietów możesz też uruchomić bezpośrednio w adb bez konieczności wpisywania 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ć sobie tworzenie i testowanie aplikacji do zarządzania urządzeniami, wydawaj polecenia do narzędzia menedżera zasad dotyczących urządzeń (dpm). Za pomocą tego narzędzia możesz kontrolować aktywną aplikację administratora lub zmienić dane o stanie zasad na urządzeniu.

W powłoce dpmskładnia to:

dpm command

Polecenie menedżera zasad dotyczących urządzeń możesz też uruchomić bezpośrednio z adb bez wpisywania 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 zrzutu ekranu urządzenia.

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

screencap filename

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

adb shell screencap /sdcard/screen.png

Oto przykład sesji zrzutu ekranu za pomocą powłoki adb do zrobienia zrzutu ekranu oraz polecenia pull, aby pobrać plik z urządzenia:

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

Nagraj film

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

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

screenrecord [options] filename

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

adb shell screenrecord /sdcard/demo.mp4

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

Jeśli chcesz nagrywać ekran urządzenia, uruchom polecenie screenrecord. 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 z wybraną szybkością transmisji bitów, zachowując proporcje wyświetlacza urządzenia. Narzędzie domyślnie rejestruje w rozdzielczości i orientacji natywnego ekranu (maksymalnie 3 minuty).

Ograniczenia narzędzia screenrecord:

• Plik wideo nie rejestruje dźwięku.
• Nagrywanie filmów nie jest dostępne na urządzeniach z Wear OS.
• Niektóre urządzenia mogą nie być w stanie nagrywać w natywnej rozdzielczości ekranu. Jeśli wystąpią problemy z nagrywaniem ekranu, spróbuj ustawić niższą rozdzielczość.
• Obracanie ekranu podczas nagrywania nie jest obsługiwane. Jeśli podczas nagrywania ekran zostanie obrócony, jego część zostanie ucięta.

Tabela 4. Opcje: screenrecord

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

Odczyt profili ART dla aplikacji

Od Androida 7.0 (poziom interfejsu API 24) środowisko Android Runtime (ART) gromadzi profile wykonywania zainstalowanych aplikacji, które służą do optymalizacji wydajności aplikacji. Przeanalizuj zebrane profile, aby dowiedzieć się, które metody są często wykonywane i które klasy są używane podczas uruchamiania aplikacji.

Uwaga: nazwę pliku profilu wykonania możesz pobrać tylko wtedy, gdy masz dostęp roota do systemu plików, na przykład przy użyciu emulatora.

Aby utworzyć formę tekstową informacji z profilu, użyj następującego polecenia:

adb shell cmd package dump-profiles package

Aby pobrać wygenerowany plik, użyj polecenia:

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

Resetowanie urządzeń testowych

Jeśli testujesz aplikację na kilku urządzeniach testowych, może się przydać resetowanie urządzenia między testami, na przykład w celu usunięcia danych użytkownika i zresetowania środowiska testowego. Możesz przywrócić ustawienia fabryczne na urządzeniu testowym z Androidem 10 (poziom interfejsu API 29) lub nowszym, korzystając z polecenia powłoki testharness adb, jak pokazano poniżej:

adb shell cmd testharness enable

Podczas przywracania urządzenia za pomocą funkcji testharness urządzenie automatycznie tworzy kopię zapasową klucza RSA, co umożliwia debugowanie za pomocą bieżącej stacji roboczej w stałej lokalizacji. Oznacza to, że po zresetowaniu urządzenia stacja robocza może nadal debugować i wydawać polecenia adb na urządzeniu bez ręcznego rejestrowania nowego klucza.

Aby testowanie aplikacji było łatwiejsze i bezpieczniejsze, przywrócenie urządzenia za pomocą polecenia testharness spowoduje też zmianę tych ustawień:

• Na urządzeniu zostaną skonfigurowane określone ustawienia systemowe, aby kreatory początkowej konfiguracji urządzenia nie były wyświetlane. Oznacza to, że urządzenie wchodzi w stan, z którego możesz szybko zainstalować, debugować i przetestować 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 Twoja aplikacja musi wykryć i dostosować domyślne ustawienia polecenia testharness, użyj ActivityManager.isRunningInUserTestHarness().

SQlite

sqlite3 uruchamia program wiersza poleceń sqlite do badania baz danych SQLite. Zawiera on polecenia, takie jak .dump, które umożliwiają wydrukowanie zawartości tabeli, i .schema, która pozwala wydrukować instrukcję SQL CREATE dla 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 możesz uzyskać tylko wtedy, gdy masz dostęp roota do systemu plików, na przykład za pomocą emulatora.

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

Backendy adb USB

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

Możesz wybrać backend, korzystając ze zmiennej środowiskowej ADB_LIBUSB. Jeśli nie będzie skonfigurowana, adb będzie używać swojego domyślnego backendu. Domyślne działanie różni się w zależności od systemu operacyjnego. Od poziomu interfejsu API 34 domyślnie używany jest backend natywny. Jeśli jest skonfigurowana ADB_LIBUSB, określa, czy używany jest natywny backend czy libusb. Więcej informacji o zmiennych środowiskowych adb znajdziesz na stronie z podręcznikiem adb.

Backendy adb mDNS

ADB może użyć protokołu DNS multicast, aby automatycznie połączyć serwer i urządzenia. Serwer ADB jest wyposażony w 2 backendy: Bonjour (mdnsResponder firmy Apple) i Openscreen.

Backend Bonjour wymaga, aby na hoście był uruchomiony demon. W systemie macOS wbudowany demon Apple jest zawsze uruchomiony, ale w systemach Windows i Linux użytkownik musi upewnić się, że demon mdnsd działa. Jeśli polecenie adb mdns check zwraca błąd, prawdopodobnie ADB korzysta z backendu Bonjour, ale nie działa żaden demon Bonjour.

Backend Openscreen nie wymaga, aby na komputerze był uruchomiony demon. Obsługa backendu w systemie Openscreen w systemie macOS rozpoczyna się od ADB w wersji 35. Od ADB w wersji 34 obsługiwane są systemy Windows i Linux.

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