Przeczytaj raporty o błędach

Błędy pojawiają się na każdym etapie rozwoju – a raporty o błędach mają kluczowe znaczenie przy identyfikowaniu i rozwiązywaniu problemów. Obsługa wszystkich wersji Androida rejestrowanie raportów o błędach na Androidzie Debug Bridge (adb); Android w wersji 4.2 i nowszych obsługuje Dla programistów Opcja zgłaszania błędów i udostępniania plików e-mailem, na Dysku itp.

Raporty o błędach z Androida zawierają: dumpsys, dumpstate i Dane logcat w formacie tekstowym (.txt), które ułatwiają wyszukiwanie dla konkretnych treści. W sekcjach poniżej znajdziesz szczegółowe informacje o komponentach raportu o błędach. opisać typowe problemy, podać przydatne wskazówki oraz polecenia grep; za znalezienie dzienników powiązanych z tymi błędami. Większość sekcji zawiera też przykłady dla polecenia i danych wyjściowych grep lub danych wyjściowych dumpsys.

Logcat

Dziennik logcat to oparty na ciągach zrzut wszystkich logcat i informacjami o nich. Część system jest zarezerwowana dla platformy, ma dłuższą historię niż element main, który obejmuje wszystkie pozostałe. Każdy wiersz zwykle zaczyna się od timestamp UID PID TID log-level, chociaż aplikacja UID może nie być widoczna w starszych wersjach Androida.

Wyświetlanie dziennika zdarzeń

Ten dziennik zawiera ciągi reprezentacyjne komunikatów logu w formacie binarnym. it jest mniej zaszumiony niż log logcat, ale trochę trudniej go odczytać. Podczas przeglądania dzienników zdarzeń w tej sekcji możesz wyszukać konkretny identyfikator procesu (PID), aby sprawdzić działanie danego procesu. Podstawowy format to: timestamp PID TID log-level log-tag tag-values

Poziomy rejestrowania obejmują:

  • V: szczegółowy
  • D: debugowanie
  • I: informacje
  • W: ostrzeżenie
  • E: błąd

 

Inne przydatne tagi dziennika zdarzeń znajdziesz w tych artykułach: /services/core/java/com/android/server/EventLogTags.logtags.

Błędy ANR i blokady wzajemnie

Zgłoszenia błędów mogą pomóc w znalezieniu przyczyny Zastosowanie Błędy ANR (brak odpowiedzi) i zakleszczenie.

Identyfikuj aplikacje, które nie reagują

Jeśli aplikacja nie odpowie w określonym czasie, zwykle z powodu zablokowany lub zajęty główny wątek, system kończy proces i zrzuca stos do /data/anr Aby wykryć przyczynę błędu ANR, użyj grep am_anr.

Możesz też grepować na ANR in w dzienniku logcat, który zawiera więcej informacji o tym, które funkcje procesora były używane w momencie błędu ANR.

Znajdź zrzuty stosu

Często można znaleźć zrzuty stosu powiązane z błędem ANR. Upewnij się, że parametr sygnatura czasowa i PID w śladach maszyny wirtualnej pasują do analizowanego błędu ANR, a następnie sprawdzić główny wątek procesu. Pamiętaj:

  • Wątek główny zawiera informacje tylko o tym, co robił w momencie utworzenia ANR, które mogą, ale nie muszą, odpowiadać rzeczywistej przyczynie błędu ANR. (wahania raport o błędzie może być niewinny; coś innego mogło utknęło na długi czas. ale nie na tyle długo, by doszło do błędu ANR, zanim coś się nie zablokuje).
  • więcej niż jeden zestaw zrzutów stosu (VM TRACES JUST NOW i VM TRACES AT LAST ANR). Upewnij się, że wyświetlana jest wartość w odpowiedniej sekcji.

Znajdowanie blokad wzajemnych

Blokady wzajemnie występują na początku jako błędy ANR, ponieważ wątki się blokują. Jeśli gdy zakleszcze na serwerze systemowym, watchdog go zabije co prowadzi do wpisu w dzienniku podobnego do: WATCHDOG KILLING SYSTEM PROCESS Z perspektywy użytkownika urządzenie uruchamia się ponownie, chociaż technicznie jest to ponowne uruchomienie środowiska wykonawczego, .

  • Po ponownym uruchomieniu w środowisku wykonawczym serwer systemu umiera i zostaje ponowne uruchomienie; użytkownik widzi, jak urządzenie powraca do animacji rozruchu.
  • Podczas restartu jądro uległo awarii. użytkownik widzi na urządzeniu pojawiło się logo rozruchowe Google.

Aby znaleźć blokady wzajemnie, w sekcjach logów czasu maszyny wirtualnej poszukaj wzorca wątku A oczekiwanie na coś trzymanego przez wątek B, który z kolei czeka na coś objęte przez wątek A.

Działania

Działanie. to komponent aplikacji, który udostępnia ekran, z którym użytkownicy mogą wchodzić w interakcje Może na przykład wybrać numer, zrobić zdjęcie, wysłać e-maila itp. z perspektywy raportu, aktywność jest pojedynczą, sprecyzowaną czynnością, którą użytkownik może wykonać, wskazującą był bardzo ważny podczas wypadku. Działania (przez ActivityManager) uruchamianie procesów, dzięki czemu zlokalizowanie wszystkich zatrzymania i rozpoczęcia danego działania może być ułatwiają też rozwiązywanie problemów.

Wyświetl wyróżnione działania

Aby wyświetlić historię wybranych aktywności, wyszukaj am_focused_activity

Wyświetl rozpoczęcia procesu

Aby wyświetlić historię rozpoczęcia procesu, wyszukaj Start proc.

Sprawdź, czy urządzenie się szarzy

Aby określić, czy urządzenie thrashing, sprawdź nietypowe wzrosty aktywności w okolicy am_proc_died i am_proc_start w krótkim czasie.

Pamięć

Urządzenia z Androidem często mają ograniczoną pamięć fizyczną, dlatego zarządzanie Pamięć RAM jest niezbędna. Raport o błędach zawiera kilka wskaźników małej ilości pamięci, a także stan zrzutu, który tworzy zrzut pamięci.

Rozpoznaj mało pamięci

Mała ilość pamięci może spowodować, że system będzie niestabilny, ponieważ spowoduje zwolnienie niektórych procesów ale wciąż uruchamia inne procesy. Aby zapoznać się z potwierdzonymi dowodami mało pamięci, sprawdź stężenie am_proc_died i Wpisy w dzienniku zdarzeń binarnego: am_proc_start.

Mała ilość pamięci może również spowolnić przełączanie zadań i utrudnić próby powrotu (ponieważ zadanie, do którego użytkownik próbował wrócić, zostało zakończone). Jeśli program uruchamiający był gdy użytkownik dotknie przycisku ekranu głównego, a w dziennikach widać launcher ponownie wczytuje zawartość.

Wyświetl wskaźniki historyczne

Wpis am_low_memory w binarnym dzienniku zdarzeń wskazuje zakończył się ostatni proces w pamięci podręcznej. Po tym czasie system rozpocznie kończenie usług.

Wyświetl wskaźniki thrash

Inne wskaźniki thrashingu systemu (stronicowania, bezpośredniego odzyskiwania itp.) to: Aplikacje kswapd, kworker i mmcqd zużywają treści cykliczną. (Pamiętaj, że zebrany raport o błędzie może wpływać na wskaźniki).

Dzienniki ANR mogą dostarczyć podobne podsumowanie pamięci.

Pobierz zrzut pamięci

Zrzut pamięci to stan zrzutu, który zawiera listę uruchomionych w Javie i plików natywnych (szczegółowe informacje znajdziesz tutaj: Wyświetlanie ogólne przydziały pamięci). Pamiętaj, że zrzut zawiera tylko informacje o stanie w określonym momencie; system mógł działać lepiej (lub gorzej) przed wykonaniem zrzutu dysku.

Nadawanie

Aplikacje generują transmisje, aby wysyłać zdarzenia w bieżącym lub do innej aplikacji. Odbiorcy transmisji subskrybują konkretne wiadomości (za pomocą filtrów), umożliwiając ich odsłuchiwanie oraz odpowiadanie na transmisję. Raporty o błędach zawierają informacje o wysłanych i niewysłanych transmisjach. a także zrzuty wszystkich odbiorników słuchających konkretnej transmisji.

Wyświetlanie transmisji historycznych

Transmisje historyczne to te, które zostały już wysłane, oraz są wymienione w w odwrotnej kolejności chronologicznej.

Sekcja Podsumowanie zawiera przegląd ostatnich 300 statystyk transmisji na pierwszym planie i ostatnich 300 transmisji w tle.

Sekcja szczegóły zawiera pełne informacje dotyczące ostatnich 50 transmisji na pierwszym planie i 50 ostatnich w tle, a także odbiornikami każdej wiadomości. Odbiorniki:

  • BroadcastFilter wpis jest zarejestrowany w czasie działania i wysyłany do już uruchomionych procesów.
  • Wpis ResolveInfo jest zarejestrowany przy użyciu wpisów manifestu. ActivityManager rozpoczyna proces w przypadku każdego elementu ResolveInfo, jeśli jest on nie jest jeszcze uruchomiona.

Wyświetl aktywne transmisje

Aktywne komunikaty to takie, które nie zostały jeszcze wysłane. Duża liczba w kolumnie oznacza, że system nie jest w stanie wysłać transmisji dostatecznie szybko, aby nadążyć.

Wyświetl detektorów transmisji

Aby wyświetlić listę odbiorników nasłuchujących transmisji, sprawdź odbiornik Tabela resolvera w dumpsys activity broadcasts. Poniżej przykład pokazuje wszystkie odbiorniki nasłuchujące USER_PRESENT.

Monitorowanie rywalizacji

Logowanie rywalizacji może czasami wskazywać na rzeczywistą rywalizację o monitor ale najczęściej wskazuje, że system jest tak przeładowany, że wszystko działa wolniej. W dzienniku systemowym lub dziennika zdarzeń mogą pojawić się długie zdarzenia monitorowania.

W dzienniku systemowym:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

W dzienniku zdarzeń:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

Kompilacja tła

Kompilacja może być kosztowna i wymagać obciążenia urządzenia.

Kompilacja może nastąpić w tle, jeśli aktualizacje Sklepu Google Play są pobieranie. W takim przypadku wiadomości z aplikacji Sklep Google Play (finsky) i installd pojawiają się przed dex2oat wiadomości.

Kompilacja może również nastąpić w tle podczas ładowania aplikacji to plik .dex, który nie został jeszcze skompilowany. W takim przypadku nie zobaczysz Logowanie finsky lub installd.

Narracja

opis problemu (jak się zaczęło, co się wydarzyło, jak to było); zareagował system) wymaga solidnego harmonogramu zdarzeń. Za pomocą informacje w raporcie o błędach, aby synchronizować osie czasu w wielu logach określić dokładną sygnaturę czasową zgłoszenia.

Synchronizuj osie czasu

Raport o błędzie pokazuje wiele równoległych osi czasu: dziennik systemowy, dziennik zdarzeń, dziennika jądra oraz wyspecjalizowane oś czasu dla komunikatów, statystyk baterii itp. Niestety ramy czasowe są często podawane w oparciu o różne przedziały czasowe.

Sygnatury czasowe dziennika systemowego i dziennika zdarzeń są podane w tej samej strefie czasowej co użytkownik to większość pozostałych sygnatur czasowych). Na przykład po kliknięciu przycisku ekranu głównego raporty z dziennika systemowego:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

W przypadku tej samej czynności dziennik zdarzeń raportuje:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Logi jądra (dmesg) używają innej podstawy czasowej i tagują elementy logu w sekundach od zakończenia programu rozruchowego. Aby zarejestrować ten zakres czasu w innym harmonogramy, wyszukaj wiadomości zawieś wyjście i zawieś wpis:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

Ponieważ logi jądra mogą nie zawierać czasu w stanie zawieszenia, będzie rejestrować dziennik między komunikatami wejściowymi i wyjściowymi. Dodatkowo logi jądra używają strefy czasowej UTC i muszą być dostosowane do użytkownika strefy czasowej.

Określ czas zgłoszenia błędu

Aby ustalić, kiedy został wygenerowany błąd, sprawdź dziennik systemowy (Logcat) dla dumpstate: begin:

10-03 17:19:54.322 19398 19398 I dumpstate: begin

Następnie sprawdź sygnatury czasowe komunikatu z Starting service 'bugreport' w logu jądra (dmesg):

<5>[207064.285315] init: Starting service 'bugreport'...

Cofnij się, aby skorelować te 2 zdarzenia, pamiętając o zastrzeżeniach wspomniane w artykule Synchronizowanie osi czasu. Istnieje wiele które pojawiają się po zainicjowaniu raportu, większość działań nie jest zbyt przydatna, raport o błędach znacząco obciąża system.

Zasilanie

Dziennik zdarzeń zawiera stan zasilania ekranu, gdzie 0 oznacza wyłączenie ekranu, a 1 – ekran włączony, a 2 – blokada klawiszy.

Raporty o błędach zawierają też statystyki dotyczące blokad uśpienia, mechanizmu używanego przez programistów aplikacji, aby wskazać, że ich aplikacje muszą mieć urządzenie nie wyłączaj. Szczegółowe informacje na temat blokad uśpienia znajdziesz w artykule PowerManager.WakeLock i Keep i włączony procesor).

Zbiorcze statystyki czasu trwania blokady uśpienia śledzą tylko za każdym razem, gdy blokada uśpienia odpowiada za uśpienie urządzenia i nie uwzględniaj czasu przy włączonym ekranie. Ponadto, jeśli jeśli jednocześnie jest nałożonych kilka blokad uśpienia, czas trwania blokady wybudzenia wynosi w obrębie poszczególnych blokad uśpienia.

Aby ułatwić sobie wizualizację stanu zasilania, używaj Historia baterii, Narzędzie open source od Google do analizy użytkowników baterii za pomocą raportu o błędzie Androida .

Pakiety

Sekcja DUMP OF SERVICE package zawiera wersje aplikacji (oraz inne przydatne informacje) ).

Procesy

Raporty o błędach zawierają mnóstwo danych dotyczących procesów, w tym czas zatrzymania, czas działania, powiązane usługi, wynik oom_adj itp. Szczegółowe informacje o tym, jak Android zarządza procesami, znajdziesz w artykule Procesy i Threads.

Określ czas działania procesu

Sekcja procstats zawiera pełne statystyki dotyczące okresu uruchomione procesy i powiązane usługi. Na szybko, w czytelny dla człowieka podsumowania, wyszukaj AGGREGATED OVER, by wyświetlić dane z ostatnie trzy lub 24 godziny, a następnie wyszukaj Summary:, aby wyświetlić listę jak długo te procesy przebiegają pod kątem różnych priorytetów, Wykorzystanie pamięci RAM w formacie min-average-max PSS/min-average-max USS.

Przyczyny uruchomienia procesu

Sekcja dumpsys activity processes zawiera obecnie wszystkie uruchomione procesy uporządkowane według wyniku oom_adj (Android wskazuje znaczenie procesu, przypisując procesowi wartość oom_adj, która może być aktualizowane dynamicznie przez usługę ActivityManager). Dane wyjściowe są podobne do tych zrzut pamięci, ale zawiera dodatkowe o przyczynach uruchomienia procesu. W przykładzie poniżej pogrubione wpisy oznaczają, że proces gms.persistent jest uruchomiony z priorytetem vis (widocznym), ponieważ proces systemowy jest powiązany z to NetworkLocationService.

Skanowania

Wykonaj poniższe czynności, aby zidentyfikować aplikacje, które mają zbyt dużą wydajność Skanowanie Bluetooth Low Energy (BLE):

  • Znajdź komunikaty logu dotyczące reguły BluetoothLeScanner: 
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
  • Znajdź identyfikator PID w komunikatach logu. W tym przykładzie: „24840” oraz „24851” to PID (identyfikator procesu) i TID (identyfikator wątku).
  • Znajdź aplikację powiązaną z identyfikatorem PID: 
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}

    W tym przykładzie nazwa pakietu to com.badapp.

  • Wyszukaj nazwę pakietu w Google Play, aby zidentyfikować osobę odpowiedzialną za nie. aplikacja: https://play.google.com/store/apps/details?id=com.badapp

Uwaga: na urządzeniach z Androidem 7.0 system zbiera dane na potrzeby skanowania BLE i wiąże te aktywności z aplikacją inicjującą. Więcej informacji: Low Energy (LE) i skanowania Bluetooth.