Biblioteki udostępnione Androida ewoluują z czasem. Utrzymywanie aktualności gotowych binarnych plików wymaga znacznego wysiłku. W Androidzie 9 lub starszym gotowe pliki binarne, które zależą od usuniętych bibliotek lub ABI, nie mogą zostać połączone w czasie wykonywania. Deweloperzy muszą przeanalizować logi, 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ę, a które muszą zostać ponownie skompilowane.
Sprawdzanie użycia interfejsu ABI na podstawie symboli
Sprawdzacz użycia ABI na podstawie symboli emuluje dynamiczny linker Androida na hoście. Sprawdza ona zależności w prekompilowanym binarnym pliku wykonywalnym i sprawdza, czy wszystkie niezdefiniowane symbole zostały rozwiązane.
Najpierw sprawdza architekturę docelową w gotowym binarnym pliku. Jeśli gotowy binarny nie jest przeznaczony dla architektury ARM, AArch64, x86 ani x86-64, sprawdzanie pomija gotowy binarny.
Po drugie, zależności w kompilowanym binarnym muszą być wymienione w LOCAL_SHARED_LIBRARIES
lub shared_libs
. System kompilacji przekształca nazwy modułów w odpowiednią wersję (np. core
lub vendor
) udostępnionych bibliotek.
Po trzecie, sprawdzacz porównuje wpisy DT_NEEDED
z LOCAL_SHARED_LIBRARIES
lub shared_libs
. W szczególności sprawdza, czy z każdej biblioteki współdzielonej wyodrębniony został element DT_SONAME
, i porównuje te elementy DT_SONAME
z elementami DT_NEEDED
zapisanymi w kompilowanym pliku binarnym. W przypadku niezgodności zostanie wyświetlony komunikat o błędzie.
Po czwarte, sprawdzacz rozwiązuje niezdefiniowane symbole w kompilowanym binarnym pliku. 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 binarnym pliku wykonywalnym 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 wstępnie skompilowany plik binarny pomijał sprawdzanie pliku ELF, określ jedną z tych opcji:
- Android.bp:
check_elf_files: false,
- Android.mk:
LOCAL_CHECK_ELF_FILES := false
Uruchamianie sprawdzania
Sprawdzanie obejmuje wszystkie wstępnie skompilowane moduły ELF podczas procesu kompilacji Androida.
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 naprawiacz 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 naprawiania 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>