Biblioteki udostępnione Androida co jakiś czas się zmieniają. Przechowywanie gotowych plików binarnych wymaga sporego wysiłku. Android 9 gotowe pliki binarne zależne tylko od usuniętych bibliotek lub interfejsów ABI nie udało się połączyć w czasie wykonywania. Deweloperzy muszą prześledzić logi, aby znaleźć nieaktualne oprogramowanie. gotowych plików binarnych. W Androidzie 10 interfejs ABI oparty na symbolach narzędzie do sprawdzania wykorzystania Narzędzie do sprawdzania może wykrywać nieaktualne gotowe pliki binarne w czasie kompilacji, dzięki czemu deweloperzy zasobów wspólnych wiedzą, zmiany mogą spowodować uszkodzenie plików binarnych i określić, które gotowe pliki binarne z powrotem.
Oparty na symbolach wskaźnik wykorzystania interfejsu ABI
Oparte na symbolach narzędzie do sprawdzania wykorzystania ABI emuluje na hoście dynamiczny tag łączący Androida. Moduł sprawdzania łączy gotowy plik binarny z zależnościami gotowego pliku binarnego binarny i sprawdza, czy wszystkie niezdefiniowane symbole zostały usunięte.
Najpierw narzędzie sprawdza architekturę docelową gotowego pliku binarnego. Jeśli gotowy plik binarny nie jest kierowany na architekturę ARM, AArch64, x86 ani x86-64, pomija gotowy plik binarny.
Po drugie: zależności gotowego pliku binarnego
LOCAL_SHARED_LIBRARIES lub shared_libs. System kompilacji rozwiązuje moduł
nazwy pasującej wariantu (np. core vs. vendor) wspólnego wariantu
biblioteki.
Po trzecie, narzędzie porównuje pozycje DT_NEEDED z wartością LOCAL_SHARED_LIBRARIES
lub shared_libs. Narzędzie do sprawdzania wyodrębnia w szczególności wpis DT_SONAME z:
wszystkich bibliotek udostępnionych i porównuje te DT_SONAME z biblioteką DT_NEEDED
zapisane w gotowym pliku binarnym. W przypadku niezgodności pojawi się komunikat
jest wysyłany komunikat.
Po czwarte, narzędzie sprawdza niezdefiniowane symbole w gotowym pliku binarnym. Te wartości
niezdefiniowane symbole muszą być zdefiniowane w jednej z zależności i symbolu
powiązanie musi mieć wartość GLOBAL lub WEAK. Jeśli niezdefiniowany symbol nie może być
został rozwiązany, pojawia się komunikat o błędzie.
Właściwości gotowego modułu
Zależności tego pliku binarnego muszą być określone w jednym z tych elementów:
- Android.bp:
shared_libs: ["libc", "libdl", "libm"], - Android.mk:
LOCAL_SHARED_LIBRARIES := libc libdl libm
Jeśli gotowy plik binarny jest zaprojektowany w taki sposób, by zawierał nierozwiązane, niezdefiniowane , wybierz jeden z tych elementów:
- Android.bp:
allow_undefined_symbols: true, - Android.mk:
LOCAL_ALLOW_UNDEFINED_SYMBOLS := true
Aby gotowy plik binarny pomijał sprawdzanie pliku ELF, podaj jeden z :
- Android.bp:
check_elf_files: false, - Android.mk:
LOCAL_CHECK_ELF_FILES := false
Uruchamianie sprawdzania
Moduł sprawdzania obejmuje wszystkie gotowe moduły ELF podczas kompilacji Androida.
Aby przyspieszyć proces sprawdzania, uruchamiając tylko narzędzie:
m check-elf-files
Naprawianie błędów ABI
Automatyczne narzędzie poprawia błędy, aby naprawić błędy interfejsu ABI. Po prostu uruchom poprawkę za pomocą
Android.bp lub Android.mk, a poprawka wyświetli sugerowane
Napraw do stanu stdout. Opcjonalnie uruchom poprawkę z opcją --in-place, aby:
bezpośrednio zaktualizuj plik Android.bp lub Android.mk, wprowadzając sugerowaną poprawkę.
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 przypadku 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>