Gotowe narzędzie do sprawdzania zastosowań ABI

Biblioteki udostępnione Androida ewoluują z czasem. Utrzymywanie aktualności gotowych binarnych plików wymaga znacznego wysiłku. W Androidzie 9 i starszych gotowych plików binarnych zależnych od usuniętych bibliotek lub interfejsów ABI nie można połączyć tylko w czasie działania. Deweloperzy muszą prześledzić dzienniki, aby znaleźć przestarzałe wstępnie skompilowane pliki binarne. W Androidzie 10 wprowadzono sprawdzanie użycia ABI na podstawie symboli. Sprawdzacz może wykrywać nieaktualne gotowe binarne pliki binarne w czasie kompilacji, aby deweloperzy bibliotek wspólnych wiedzieli, które gotowe binarne pliki binarne mogą być uszkodzone przez ich zmianę i które z nich muszą zostać ponownie skompilowane.

Sprawdzanie użycia interfejsu ABI na podstawie symboli

Oparte na symbolach narzędzie do sprawdzania wykorzystania ABI emuluje na hoście dynamiczny tag łączący Androida. Sprawdza on, czy wszystkie niezdefiniowane symbole zostały rozwiązane.

Najpierw sprawdza architekturę docelową w gotowym binarnym pliku. Jeśli gotowy binarny plik nie jest przeznaczony dla architektury ARM, AArch64, x86 ani x86-64, sprawdzanie pomija gotowy binarny plik.

Po drugie, zależności w kompilowanym binarnym muszą być wymienione w LOCAL_SHARED_LIBRARIES lub shared_libs. System kompilacji przypisuje nazwy modułów do pasującego wariantu (np. core w porównaniu z vendor) udostępnianych bibliotek.

Po trzecie, sprawdzacz porównuje wpisy DT_NEEDED z LOCAL_SHARED_LIBRARIES lub shared_libs. W szczególności narzędzie do sprawdzania wyodrębnia wpis DT_SONAME z każdej biblioteki udostępnionej i porównuje go DT_SONAME z DT_NEEDEDwpisami zarejestrowanymi w gotowym pliku binarnym. W przypadku niezgodności zostanie wyświetlony komunikat o błędzie.

Po czwarte, narzędzie sprawdza niezdefiniowane symbole w gotowym pliku binarnym. Te symbole muszą być zdefiniowane w jednej z zależności, a powiązanie symboli musi być albo GLOBAL albo WEAK. Jeśli nie można rozwiązać niezdefiniowanego symbolu, zostanie wyświetlony komunikat o błędzie.

Właściwości modułu gotowego

Zależnośći w gotowym pliku binarnym muszą być określone w jednym z tych dokumentów:

  • Android.bp: shared_libs: ["libc", "libdl", "libm"],
  • Android.mk: LOCAL_SHARED_LIBRARIES := libc libdl libm

Jeśli gotowy plik binarny ma zawierać nierozwiązywalne niezdefiniowane symbole, określ jedno z tych ustawień:

  • Android.bp: allow_undefined_symbols: true,
  • Android.mk: LOCAL_ALLOW_UNDEFINED_SYMBOLS := true

Aby gotowy plik binarny pomijał sprawdzanie pliku ELF, wybierz jedną z tych opcji:

  • Android.bp: check_elf_files: false,
  • Android.mk: LOCAL_CHECK_ELF_FILES := false

Uruchamianie sprawdzania

Podczas procesu kompilacji Androida sprawdzacz obejmuje wszystkie wstępnie skompilowane moduły ELF.

Aby uruchomić sprawdzarkę bez korzystania z innych narzędzi, co pozwoli skrócić czas przetwarzania:

m check-elf-files

Narzędzia do naprawy błędów interfejsu ABI

Automatyczny program naprawczy może pomóc w rozwiązywaniu błędów sprawdzania ABI. Wystarczy uruchomić narzędzie z plikiem Android.bp lub Android.mk jako wejściem, a narzędzie wydrukuje sugerowane poprawki na wyjściu standardowym. Opcjonalnie możesz uruchomić narzędzie do naprawy z opcją --in-place, aby bezpośrednio zaktualizować plik Android.bp lub Android.mk za pomocą sugerowanej poprawki.

W przypadku Android.bp:

m fix_android_bp_prebuilt
# Print the fixed Android.bp to stdout.
fix_android_bp_prebuilt <path-to-Android.bp>
# Update the Android.bp in place.
fix_android_bp_prebuilt --in-place <path-to-Android.bp>

W pliku Android.mk:

m fix_android_mk_prebuilt
# Print the fixed Android.mk to stdout.
fix_android_mk_prebuilt <path-to-Android.mk>
# Update the Android.mk in place.
fix_android_mk_prebuilt --in-place <path-to-Android.mk>