Biblioteki udostępnione Androida są co jakiś czas aktualizowane. Utrzymywanie aktualności wstępnie skompilowanych plików binarnych wymaga znacznego wysiłku. W Androidzie 9 lub starszym wstępnie skompilowane pliki binarne, które zależą od usuniętych bibliotek lub interfejsów ABI, nie są łączone tylko w czasie działania. Deweloperzy muszą prześledzić logi, aby znaleźć nieaktualne wstępnie skompilowane pliki binarne. W Androidzie 10 wprowadzono narzędzie do sprawdzania użycia interfejsu ABI na podstawie symboli. Narzędzie to może wykrywać nieaktualne wstępnie skompilowane pliki binarne w czasie kompilacji, dzięki czemu deweloperzy bibliotek udostępnionych mogą wiedzieć, które wstępnie skompilowane pliki binarne mogą zostać uszkodzone przez ich zmiany i które z nich trzeba ponownie skompilować.
Narzędzie do sprawdzania użycia interfejsu ABI na podstawie symboli
Narzędzie do sprawdzania użycia interfejsu ABI na podstawie symboli emuluje dynamiczny linker Androida na hoście. Narzędzie łączy wstępnie skompilowany plik binarny z jego zależnościami i sprawdza, czy wszystkie niezdefiniowane symbole zostały rozwiązane.
Najpierw narzędzie sprawdza architekturę docelową wstępnie skompilowanego pliku binarnego. Jeśli wstępnie skompilowany plik binarny nie jest przeznaczony dla architektury ARM, AArch64, x86 lub x86-64, narzędzie pomija ten plik.
Po drugie, zależności wstępnie skompilowanego pliku binarnego muszą być wymienione w LOCAL_SHARED_LIBRARIES lub shared_libs. System kompilacji rozwiązuje nazwy modułów na pasujący wariant (np. core vs. vendor) bibliotek udostępnionych.
Po trzecie, narzędzie porównuje wpisy DT_NEEDED z LOCAL_SHARED_LIBRARIES lub shared_libs. W szczególności narzędzie wyodrębnia wpis DT_SONAME z każdej biblioteki udostępnionej i porównuje te wpisy DT_SONAME z wpisami DT_NEEDED zapisanymi we wstępnie skompilowanym pliku binarnym. Jeśli wystąpi niezgodność, pojawi się komunikat o błędzie.
Po czwarte, narzędzie rozwiązuje niezdefiniowane symbole we wstępnie skompilowanym pliku binarnym. Te niezdefiniowane symbole muszą być zdefiniowane w jednej z zależności, a powiązanie symboli musi być GLOBAL lub WEAK. Jeśli nie można rozwiązać niezdefiniowanego symbolu, pojawi się komunikat o błędzie.
Właściwości modułu wstępnie skompilowanego
Zależności wstępnie skompilowanego pliku binarnego muszą być określone w jednym z tych miejsc:
- Android.bp:
shared_libs: ["libc", "libdl", "libm"], - Android.mk:
LOCAL_SHARED_LIBRARIES := libc libdl libm
Jeśli wstępnie skompilowany plik binarny ma zawierać nierozwiązywalne niezdefiniowane symbole, określ jedną z tych wartości:
- Android.bp:
allow_undefined_symbols: true, - Android.mk:
LOCAL_ALLOW_UNDEFINED_SYMBOLS := true
Aby wstępnie skompilowany plik binarny pominął sprawdzanie pliku ELF, określ jedną z tych wartości:
- Android.bp:
check_elf_files: false, - Android.mk:
LOCAL_CHECK_ELF_FILES := false
Uruchamianie narzędzia do sprawdzania
Narzędzie do sprawdzania obejmuje wszystkie wstępnie skompilowane moduły ELF podczas procesu kompilacji Androida.
Aby uruchomić narzędzie do sprawdzania samodzielnie i skrócić czas realizacji:
m check-elf-filesNarzędzie do naprawiania błędów interfejsu ABI
Automatyczne narzędzie do naprawiania może pomóc w rozwiązywaniu błędów sprawdzania interfejsu ABI. Wystarczy uruchomić narzędzie do naprawiania z plikiem Android.bp lub Android.mk jako danymi wejściowymi, a narzędzie wyświetli sugerowaną poprawkę w standardowym wyjściu. Opcjonalnie możesz uruchomić narzędzie do naprawiania z opcją --in-place, aby bezpośrednio zaktualizować plik Android.bp lub Android.mk o sugerowaną poprawkę.
W przypadku pliku 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 przypadku 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>