Usuwanie zaciemnienia kodu i symbolizacja zrzutów stosu w przypadku awarii

Aby usunąć zaciemnienie kodu Java w zrzucie stosu, najpierw musisz wygenerować plik mapowania ProGuard. Informacje o tym, jak to zrobić, znajdziesz na stronie Google Developers.

Wtyczka Androida do obsługi Gradle w wersji 4.1 lub nowszej

Jeśli w ramach projektu tworzysz pakiet Android App Bundle, możesz automatycznie uwzględnić w nim plik symboli debugowania. Aby uwzględnić ten plik, do pliku build.gradle dodaj ten ciąg:

• android.defaultConfig.ndk.debugSymbolLevel = 'FULL'

Uwaga: plik symboli debugowania może mieć maksymalnie 800 MB. Jeśli plik jest za duży, zamiast wartości FULL użyj SYMBOL_TABLE. To pozwoli zmniejszyć rozmiar pliku.

Jeśli w ramach projektu tworzysz plik APK, użyj ustawienia kompilacji build.gradle, tak by niezależnie wygenerować plik z symbolami. Prześlij ręcznie plik symboli debugowania do Konsoli Google Play zgodnie z instrukcjami z Kroku 2. (poniżej) Prześlij plik do odczytywania zaciemnionego kodu lub symbolizacji. W ramach procesu kompilacji wtyczka Androida do obsługi Gradle generuje ten plik w następującej lokalizacji projektu:

• app/build/outputs/native-debug-symbols/variant-name/native-debug-symbols.zip

Wtyczka Androida do obsługi Gradle w wersji 4.0 lub nowszej (i inne systemy kompilacji)

W ramach procesu kompilacji pakietu aplikacji lub pliku APK wtyczka Androida do obsługi Gradle przechowuje kopię niezmodyfikowanych bibliotek w katalogu projektu. Katalog ma strukturę podobną do tej:

app/build/intermediates/cmake/universal/release/obj

├── armeabi-v7a/

│   ├── libgamenegine.so

│   ├── libothercode.so

│   └── libvideocodec.so

├── arm64-v8a/

│   ├── libgamenegine.so

│   ├── libothercode.so

│   └── libvideocodec.so

├── x86/

│   ├── libgamenegine.so

│   ├── libothercode.so

│   └── libvideocodec.so

└── x86_64/

    ├── libgameengine.so

    ├── libothercode.so

    └── libvideocodec.so

Uwaga: jeśli używasz innego systemu kompilacji, możesz go zmodyfikować, by przechowywał niezmodyfikowane biblioteki w katalogu o wymaganej, podanej wyżej strukturze.

1. Skompresuj zawartość tego katalogu:
   • $ cd app/build/intermediates/cmake/universal/release/obj
   • $ zip -r symbols.zip.
2. Prześlij ręcznie plik symbols.zip do Konsoli Play zgodnie z instrukcjami podanymi poniżej w sekcji Krok 2. Prześlij plik do odczytywania zaciemnionego kodu lub symbolizacji.

Plik symboli debugowania może mieć maksymalnie 800 MB. Jeśli plik jest za duży, prawdopodobnie pliki .so zawierają tabelę symboli (nazwy funkcji) oraz dane debugowania w formacie DWARF (nazwy plików i wiersze kodu). Nie potrzebujesz ich do symbolizacji kodu. Możesz je usunąć poleceniem:

• $OBJCOPY --strip-debug lib.so lib.so.sym

Uwaga: $OBJCOPY wskazuje określoną wersję interfejsu ABI, którą upraszczasz, np.:ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-objcopy

Aby przesłać plik do odczytywania zaciemnionego kodu lub symbolizacji:

1. Otwórz Konsolę Play.
2. Wybierz aplikację.
3. W menu po lewej stronie kliknij Testuj i publikuj > Eksplorator pakietów aplikacji.
4. Za pomocą selektora w prawym górnym rogu wybierz odpowiedni artefakt.
5. Wybierz kartę Pobrane i przewiń w dół do sekcji „Zasoby”.
6. Kliknij strzałkę przesyłania pliku mapowania lub pliku symboli debugowania, aby przesłać pliki do odczytywania zaciemnionego kodu lub symbolizacji dla danej wersji aplikacji.

Aby przesłać pliki za pomocą interfejsu Google Play Developer API, otwórz stronę Google Developers.

Do symbolizacji zrzutów stosu w aplikacjach natywnych Konsola Play używa narzędzia ndk-stack, a w przypadku awarii wykonywania kodu Java – narzędzia ReTrace. Jeśli zdecydujesz się nie udostępniać plików do odczytywania zaciemnionego kodu, możesz skopiować zrzuty stosu awarii z zaciemnionym kodem z Konsoli Play i użyć odpowiedniego narzędzia offline, aby przeprowadzić ich symbolizację. Ten proces musisz przeprowadzić ręcznie dla każdego zrzutu stosu awarii, co zajmuje dużo czasu. Jeśli udostępnisz pliki do odczytywania zaciemnionego kodu, Konsola Play zajmie się tym za Ciebie.

Po przesłaniu pliku mapowania ProGuard lub pliku symboli debugowania dla danej wersji aplikacji zaciemnienie kodu będzie usuwane wyłącznie w przypadku przyszłych awarii i błędów ANR w tej wersji. Kod z usuniętym zaciemnieniem z nowych awarii i błędów ANR zgłaszanych z urządzeń użytkowników będzie widoczny w Konsoli Play dopiero po pewnym czasie.

Dzieje się tak w przypadku przesłania niekompletnych plików. Pamiętaj, aby uwzględnić pliki symbolizacji dla całej aplikacji, zwłaszcza jeśli korzystasz ze złożonego lub wieloetapowego procesu kompilacji. Jedną z najczęstszych przyczyn częściowego usunięcia zaciemnionego kodu jest używanie bibliotek innej firmy. W takim przypadku spróbuj uzyskać plik do usuwania zaciemnionego kodu od dostawcy biblioteki.

Bez plików do usuwania zaciemnienia kodu te same awarie i błędy ANR na urządzeniach 32-bitowych i 64-bitowych lub z procesorami ARM bądź Intel są wymieniane oddzielnie. Gdy udostępnisz pliki do odczytywania zaciemnionego kodu, możemy zgrupować te awarie i błędy razem, co daje Ci lepszy wgląd w problemy występujące w aplikacji.

Jeśli nie prześlesz pliku dla nowej wersji aplikacji, kod danych o awariach i błędach ANR znów zostanie zaciemniony. Aby przesłać taki plik, wykonaj instrukcje podane powyżej. Po przesłaniu pliku mapowania ProGuard lub pliku symboli debugowania dla danej wersji aplikacji zaciemnienie kodu będzie usuwane wyłącznie w przypadku przyszłych awarii i błędów ANR w tej wersji. Kod z usuniętym zaciemnieniem z nowych awarii i błędów ANR zgłaszanych z urządzeń użytkowników będzie widoczny w Konsoli Play dopiero po pewnym czasie.

Aby uchronić się przed pominięciem przesłania pliku, zmień proces kompilacji, tak by stosować w nim pakiety aplikacji z wtyczką Androida do obsługi Gradle w wersji 4.1 lub nowszej. Jeśli stosujesz ten proces, możesz automatycznie dodawać plik symboli debugowania do pakietu aplikacji, postępując według instrukcji ze strony Android Developers.

Jeśli prześlesz zły plik dla danej wersji aplikacji, awarie i błędy ANR znów będą miały zaciemniony kod. Aby przesłać prawidłową wersję:

1. Otwórz Konsolę Play.
2. Wybierz aplikację.
3. W menu po lewej stronie kliknij Testuj i publikuj > Eksplorator pakietów aplikacji.
4. Za pomocą selektora w prawym górnym rogu wybierz odpowiedni artefakt.
5. Wybierz kartę Pobrane i przewiń w dół do sekcji „Zasoby”.
6. Kliknij ikonę usuwania obok nieprawidłowego pliku do odczytywania zaciemnionego kodu lub symbolizacji.
7. Potem kliknij ikonę przesyłania i wybierz prawidłowy plik dla danej wersji aplikacji.

Po przesłaniu prawidłowego pliku mapowania ProGuard lub pliku symboli debugowania dla danej wersji aplikacji zaciemnienie kodu będzie usuwane wyłącznie w przypadku przyszłych awarii i błędów ANR w tej wersji. Kod z usuniętym zaciemnieniem z nowych awarii i błędów ANR zgłaszanych z urządzeń użytkowników będzie widoczny w Konsoli Play dopiero po pewnym czasie.

Wskazówka: aby uchronić się przed przesłaniem nieprawidłowej wersji pliku, zmień proces kompilacji, tak by stosować w nim pakiety aplikacji z wtyczką Androida do obsługi Gradle w wersji 4.1 lub nowszej. W ten sposób możesz automatycznie dodawać plik symboli debugowania do pakietu aplikacji, zgodnie z instrukcją ze strony Android Developers.

Aby dowiedzieć się, jak to zrobić, otwórz stronę Android Developers.

Tak.

Zdarza się, że system napotyka błędy ANR, ale nie jest w stanie zebrać zrzutu stosu. W takiej sytuacji pokazujemy błąd ANR, bo zapewnia on pełniejszy obraz stabilności aplikacji, ale sam zrzut stosu nie może być wyświetlony. Błędy ANR bez zrzutów stosu są pogrupowane według typu i aktywności, więc przeglądanie i poprawianie podobnych błędów może pomóc w zmniejszeniu liczby tych bez zrzutów stosu.