Android.mk

Na tej stronie opisano składnię pliku kompilacji Android.mk używanego przez ndk-build

Omówienie

Plik Android.mk znajduje się w podkatalogu jni/ projektu oraz opisuje Twoje źródła i biblioteki udostępnione w systemie kompilacji. Jest to naprawdę mały fragment pliku Makefile programu GNU, który system kompilacji analizuje raz lub i innych. Plik Android.mk przydaje się do definiowania ustawień projektu, które Application.mk, system kompilacji i zmienne środowiskowe nie będą dostępne. nie zdefiniowano. Może też zastępować ustawienia dotyczące całego projektu dla konkretnych modułów.

Składnia elementu Android.mk umożliwia grupowanie źródeł w moduły. Moduł może być biblioteką statyczną, biblioteką współdzieloną lub samodzielną . W każdym pliku Android.mk możesz zdefiniować co najmniej 1 moduł. możesz używać tego samego pliku źródłowego w kilku modułach. Tylko system kompilacji umieszcza biblioteki udostępnione w pakiecie aplikacji. Poza tym statyczna biblioteki udostępnione.

Oprócz bibliotek pakietów system kompilacji obsługuje dla Ciebie. Na przykład nie musisz wymieniać plików nagłówka ani zależności między wygenerowanymi plikami w pliku Android.mk. Kompilacja NDK automatycznie oblicza te relacje. W rezultacie powinni mieć możliwość skorzystania z nowego łańcucha narzędzi/obsługi platformy w przyszłości w NDK wersji bez dotykania pliku Android.mk.

Składnia tego pliku jest bardzo zbliżona do tej w plikach Android.mk. rozpowszechniane w ramach całego projektu Android Open Source. System kompilacji ich zastosowanie wygląda inaczej, ich podobieństwo jest celowe. decyzji projektowej ma na celu ułatwienie programistom aplikacji kod źródłowy bibliotek zewnętrznych.

Podstawy

Zanim szczegółowo zapoznasz się ze składnią, najpierw poznaj podstawowe informacje o zawartości pliku Android.mk. W tej sekcji użyto Android.mk we fragmencie Hello-JNI, wyjaśniającym rolę w każdym wierszu pliku.

Plik Android.mk musi zaczynać się od zdefiniowania zmiennej LOCAL_PATH:

LOCAL_PATH := $(call my-dir)

Ta zmienna wskazuje lokalizację plików źródłowych w wersji deweloperskiej drzewo. W tym przypadku funkcja makro my-dir udostępniona przez system kompilacji zwraca ścieżkę bieżącego katalogu (czyli katalogu zawierającego Android.mk pliku).

W następnym wierszu deklaruje się zmienną CLEAR_VARS, której wartość system kompilacji co zapewnia.

include $(CLEAR_VARS)

Zmienna CLEAR_VARS wskazuje specjalny plik GNU Makefile, który usuwa wiele LOCAL_XXX, np. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES. Pamiętaj, że nie zostanie usunięte pole LOCAL_PATH. Ten zmienna musi zachowywać swoją wartość, ponieważ system analizuje wszystkie pliki sterujące kompilacji w jednym kontekście wykonawczym GNU Make, w którym wszystkie zmienne mają charakter globalny. Musisz (ponownie) zadeklaruj tę zmienną przed opisaniem każdego modułu.

Następnie zmienna LOCAL_MODULE przechowuje nazwę modułu, który chcesz tworzyć. Użyj tej zmiennej raz w każdym module w swojej aplikacji.

LOCAL_MODULE := hello-jni

Nazwa każdego modułu musi być unikalna i nie może zawierać spacji. System kompilacji podczas generowania ostatecznego pliku biblioteki współdzielonej automatycznie dodaje odpowiednie prefiks i przyrostek nazwy przypisanej użytkownikowi LOCAL_MODULE. Przykład: Powyższy przykład generuje bibliotekę o nazwie libhello-jni.so

Uwaga: jeśli nazwa modułu zaczyna się już od lib, system kompilacji nie można dodać na początku prefiks lib; przyjmuje nazwę modułu w niezmienionej formie i dodaje makro .so. Plik źródłowy nazywał się więc np. libfoo.c nadal tworzy plik współdzielonego obiektu o nazwie libfoo.so. Takie działanie ma na celu obsługują biblioteki, które źródła platformy Androida generują na podstawie Android.mk files; nazwy wszystkich takich bibliotek zaczynają się od lib.

W następnym wierszu wymienione są pliki źródłowe, przy czym spacje oddzielają wiele pliki:

LOCAL_SRC_FILES := hello-jni.c

Zmienna LOCAL_SRC_FILES musi zawierać listę plików źródłowych w języku C lub C++ w moduł.

Ostatni wiersz pomaga systemowi powiązać ze sobą wszystkie elementy:

include $(BUILD_SHARED_LIBRARY)

Zmienna BUILD_SHARED_LIBRARY wskazuje skrypt GNU Makefile, który zbiera wszystkie informacje określone w zmiennych LOCAL_XXX od ostatnich include. Skrypt określa, co i w jaki sposób utworzyć.

W katalogach przykładów można znaleźć bardziej złożone przykłady z skomentowanymi Android.mk plików, które możesz wyświetlić. Dodatkowo Przykład: aktywność natywna zawiera szczegółowe objaśnienie pliku Android.mk tego przykładu. I na koniec, Strona Zmienne i makra zawiera dodatkowe informacje o zmiennych z tego .

Zmienne i makra

System kompilacji udostępnia wiele możliwych zmiennych do użycia w pliku Android.mk. Wiele z tych zmiennych ma wstępnie przypisane wartości. a pozostałe – samodzielnie.

Oprócz tych zmiennych możesz także definiować własne dowolne. W takim przypadku zachowaj pamiętaj, że system kompilacji NDK rezerwuje te nazwy zmiennych:

• Nazwy zaczynające się od LOCAL_, na przykład LOCAL_MODULE.
• Nazwy zaczynające się od PRIVATE_, NDK_ lub APP. System kompilacji używa wewnętrznie.
• Nazwy pisane małymi literami, np. my-dir. System kompilacji używa ich wewnętrznie, cóż.

Jeśli trzeba zdefiniować własne zmienne w pliku Android.mk, zalecamy dodanie MY_ do ich nazw.

Zmienne uwzględniania zdefiniowane przez NDK

W tej sekcji omawiamy zmienne GNU Make, które są definiowane przez system kompilacji przed analizowaniem pliku Android.mk. W pewnych okolicznościach NDK może wielokrotnie przeanalizować plik Android.mk, używając innej definicji dla niektórych z tych zmiennych.

WYCZYŚĆ_ODMIANY

Ta zmienna wskazuje skrypt kompilacji, który nie definiuje prawie wszystkich LOCAL_XXX zmiennych wymienionych na liście „Zmienne zdefiniowane przez programistę” sekcji poniżej. Użyj tej , aby uwzględnić ten skrypt przed opisaniem nowego modułu. Składnia instrukcji korzystanie z niej:

include $(CLEAR_VARS)

BUILD_EXECUTABLE

Ta zmienna wskazuje skrypt kompilacji, który zbiera wszystkie informacje na temat modułem podanym w zmiennych LOCAL_XXX oraz określa sposób utwórz docelowy plik wykonywalny na podstawie podanych źródeł. Pamiętaj, że użycie tego skrypt wymaga, aby były już przypisane wartości do LOCAL_MODULE oraz LOCAL_SRC_FILES przynajmniej (więcej informacji na temat tych zmiennych można znaleźć tutaj: zmiennych opisu modułu).

Składnia używana do użycia tej zmiennej:

include $(BUILD_EXECUTABLE)

Uwaga: większość aplikacji na Androida nie zawiera plików wykonywalnych, ale są one przydatne tworzenia testów jednostkowych i innych narzędzi do debugowania.

KOMPILD_WSPÓŁDZIELONA_BIBLIOTEKA

Ta zmienna wskazuje skrypt kompilacji, który zbiera wszystkie informacje na temat modułem podanym w zmiennych LOCAL_XXX oraz określa sposób utworzyć docelowe zasoby wspólne na podstawie podanych źródeł. Pamiętaj, że użycie tego skrypt wymaga, aby były już przypisane wartości do LOCAL_MODULE oraz LOCAL_SRC_FILES przynajmniej (więcej informacji na temat tych zmiennych można znaleźć tutaj: zmiennych opisu modułu).

Składnia używana do użycia tej zmiennej:

include $(BUILD_SHARED_LIBRARY)

Zmienna biblioteki współdzielonej powoduje, że system kompilacji generuje plik biblioteki. z rozszerzeniem .so.

BUILD_STATIC_BIBLIOTEKA

Wariant języka BUILD_SHARED_LIBRARY używany do tworzenia biblioteki statycznej. system kompilacji nie kopiuje bibliotek statycznych do projektu/pakietów, mogą za ich pomocą tworzyć biblioteki udostępnione (zobacz LOCAL_STATIC_LIBRARIES i LOCAL_WHOLE_STATIC_LIBRARIES poniżej). Składnia używana do użycia tej zmiennej:

include $(BUILD_STATIC_LIBRARY)

Zmienna biblioteki statycznej powoduje, że system kompilacji generuje bibliotekę z parametrem .a.

BIBLIOTEKA_WSTĘPNA_WSPÓLNA

Wskazuje skrypt kompilacji używany do określenia gotowej biblioteki współdzielonej. Usuń polubienie w w przypadku BUILD_SHARED_LIBRARY i BUILD_STATIC_LIBRARY, tu wartość LOCAL_SRC_FILES nie może być plikiem źródłowym. Musi to być jedna ścieżka do gotowa biblioteka współdzielona, taka jak foo/libfoo.so. Składnia używana w przypadku tego argumentu to:

include $(PREBUILT_SHARED_LIBRARY)

Możesz też odwołać się do gotowej biblioteki w innym module, używając Zmienna LOCAL_PREBUILTS. Więcej informacji o używaniu gotowych kompilacji znajdziesz w materiałach na temat Użyj gotowych bibliotek.

PREBUILT_STATIC_BIBLIOTEKA

To samo co PREBUILT_SHARED_LIBRARY, ale w przypadku gotowej biblioteki statycznej. Dla: Więcej informacji o używaniu gotowych bibliotek znajdziesz w artykule Korzystanie z gotowych bibliotek.

Docelowe zmienne informacyjne

System kompilacji analizuje Android.mk raz na interfejs ABI określony przez APP_ABI , która jest zwykle zdefiniowana w pliku Application.mk. Jeśli APP_ABI wynosi all, system kompilacji analizuje element Android.mk raz dla każdego interfejsu ABI i NDK obsługuje. W tej sekcji opisano zmienne definiowane przez system kompilacji za każdym razem, analizuje element Android.mk.

ARCH DOCELOWY

Rodzina procesorów, na którą kierowany jest system kompilacji podczas analizowania tego zasobu (Android.mk) . Zmienna będzie jedną z tych zmiennych: arm, arm64, x86 lub x86_64.

TARGET_PLATFORMA

Numer poziomu interfejsu API Androida, na który kierowany jest system kompilacji podczas analizowania tego Android.mk. Na przykład obrazy systemu Android 5.1 odpowiadają Interfejs API Androida poziomu 22: android-22. Pełną listę nazw platform odpowiednich obrazów systemu Android znajdziesz w artykule Natywne interfejsy API. przykład poniżej pokazuje składnię użycia tej zmiennej:

ifeq ($(TARGET_PLATFORM),android-22)
    # ... do something ...
endif

TARGET_ARCH_ABI

Interfejs ABI, na który kierowany jest system kompilacji podczas analizowania tego pliku Android.mk. Tabela 1 przedstawia ustawienie interfejsu ABI używane w przypadku każdego obsługiwanego procesora i architektury.

Tabela 1. Ustawienia ABI dla różnych procesorów i architektur.

Procesor i architektura	Ustawienie
ARM wersja 7	armeabi-v7a
ARMv8 AArch64	arm64-v8a
i686	x86
x86–64	x86_64

Przykład poniżej pokazuje, jak sprawdzić, czy w środowisku docelowym ARMv8 AArch64 Kombinacja procesora i interfejsu ABI:

ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
  # ... do something ...
endif

Więcej informacji o interfejsach ABI architektury i powiązanych problemach ze zgodnością znajdziesz zapoznaj się z interfejsami ABI Androida.

Nowe docelowe interfejsy ABI w przyszłości będą miały inne wartości.

TARGET_ABI

Połączenie docelowego poziomu interfejsu API Androida i interfejsu ABI. Szczególnie przydatne są gdy chcesz przeprowadzić test na konkretnym docelowym obrazie systemu na rzeczywistym urządzeniu. Aby na przykład sprawdzić, czy jest to 64-bitowe urządzenie z architekturą ARM i interfejsem API Androida na poziomie 22:

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
  # ... do something ...
endif

Zmienne opisu modułu

Zmienne w tej sekcji opisują Twój moduł w systemie kompilacji. Każdy w opisie modułu:

1. Zainicjuj lub cofnij zdefiniowanie zmiennych powiązanych z modułem za pomocą Zmienna CLEAR_VARS.
2. Przypisanie wartości do zmiennych używanych do opisania modułu.
3. Ustaw system kompilacji NDK tak, aby używał odpowiedniego skryptu kompilacji dla modułu. za pomocą zmiennej BUILD_XXX.

LOCAL_PATH

Ta zmienna podaje ścieżkę bieżącego pliku. Musisz je zdefiniować na początku pliku Android.mk. Poniższy przykład pokazuje, jak to zrobić czyli:

LOCAL_PATH := $(call my-dir)

Skrypt, na który wskazuje CLEAR_VARS, nie odczytuje tej zmiennej. Dlatego wystarczy zdefiniować go raz, nawet jeśli plik Android.mk zawiera opis wielu modułów.

MODUŁ_LOKALNY

Ta zmienna przechowuje nazwę modułu. Musi być niepowtarzalna wśród wszystkich modułów nazw i nie mogą zawierać spacji. Musisz je zdefiniować przed dodaniem skrypty (inne niż dla CLEAR_VARS). Nie musisz dodawać żadnego elementu: lib lub rozszerzenie pliku .so lub .a; system kompilacji sprawia, zmiany wprowadzane automatycznie. W okresie: Android.mk i Application.mk będą oznaczały moduł jego niezmodyfikowaną nazwą. Na przykład: spowoduje wygenerowanie modułu biblioteki udostępnionej o nazwie libfoo.so:

LOCAL_MODULE := "foo"

Jeśli chcesz, by wygenerowany moduł miał nazwę inną niż lib + wartość LOCAL_MODULE, możesz użyć zmiennej LOCAL_MODULE_FILENAME, aby podać nie może wygenerować modułu o wybranej przez Ciebie nazwie.

LOCAL_MODULE_FILENAME

Ta opcjonalna zmienna umożliwia zastępowanie nazw nadanych przez system kompilacji domyślnie używa ich w generowanych plikach. Jeśli na przykład nazwa Twojego konta LOCAL_MODULE ma wartość foo. Możesz wymusić na systemie wywołanie generowanego pliku libnewfoo Ten przykład ilustruje, jak to zrobić:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

W przypadku modułu biblioteki udostępnionej ten przykład generuje plik o nazwie libnewfoo.so

Uwaga: nie można zastąpić ścieżki ani rozszerzenia pliku.

LOCAL_SRC_FILES

Ta zmienna zawiera listę plików źródłowych, których system kompilacji używa do za wygenerowanie modułu. Wymieniaj tylko pliki przesyłane przez system kompilacji do kompilatora, ponieważ system kompilacji automatycznie zależności. Pamiętaj, że możesz używać zarówno wartości względnych (do LOCAL_PATH), jak i bezwzględnych ścieżek plików.

Zalecamy unikanie bezwzględnych ścieżek do plików. ścieżki względne sprawiają, że Android.mk bardziej przenośny.

Uwaga: w plikach kompilacji zawsze używaj ukośników w stylu Unix (/). Kompilacja system nie obsługuje poprawnie ukośników lewych (\) w stylu Windows.

LOCAL_CPP_ROZSZERZENIE

Tej opcjonalnej zmiennej można użyć do wskazania rozszerzenia pliku innego niż .cpp na pliki źródłowe w C++. Na przykład ten wiersz zmienia rozszerzenie do .cxx. (ustawienie musi zawierać kropkę).

LOCAL_CPP_EXTENSION := .cxx

Za pomocą tej zmiennej możesz określać wiele rozszerzeń. Przykłady:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

Za pomocą tej opcjonalnej zmiennej można wskazać, że kod zależy od Funkcje C++. Włącza podczas kompilacji odpowiedni kompilator i flagi łączące proces tworzenia konta. W przypadku gotowych plików binarnych ta zmienna deklaruje również funkcje plików binarnych, od których zależy działanie ostatecznego połączenia. Śr zalecamy używanie tej zmiennej zamiast włączania -frtti i -fexceptions bezpośrednio w definicji LOCAL_CPPFLAGS.

Użycie tej zmiennej pozwala systemowi kompilacji używać odpowiednich flag każdego modułu. Użycie metody LOCAL_CPPFLAGS powoduje, że kompilator używa wszystkich określonych dla wszystkich modułów, niezależnie od rzeczywistej potrzeby.

Aby na przykład wskazać, że Twój kod korzysta z RTTI (RunTime Type Information), zapis:

LOCAL_CPP_FEATURES := rtti

Aby wskazać, że w Twoim kodzie są używane wyjątki dotyczące języka C++, wpisz:

LOCAL_CPP_FEATURES := exceptions

Możesz też podać wiele wartości tej zmiennej. Na przykład:

LOCAL_CPP_FEATURES := rtti features

Kolejność, w jakiej opisujesz wartości, nie ma znaczenia.

LOCAL_C_INCLUDES

Za pomocą tej opcjonalnej zmiennej możesz określić listę ścieżek względem zmiennej Katalog NDK root, który ma zostać dodany do ścieżki uwzględniania wyszukiwania podczas kompilowania wszystkich (C, C++ i Assembly). Na przykład:

LOCAL_C_INCLUDES := sources/foo

Albo nawet:

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo

Zdefiniuj tę zmienną, zanim ustawisz odpowiednie flagi uwzględniania za pomocą opcji LOCAL_CFLAGS lub LOCAL_CPPFLAGS.

Podczas uruchamiania system kompilacji automatycznie używa też LOCAL_C_INCLUDES ścieżek na potrzeby debugowania natywnego, korzystając z ndk-gdb.

LOCAL_CFLAGS

Ta opcjonalna zmienna ustawia flagi kompilatora, które zostaną przekazane przez system kompilacji, gdy dzięki utworzeniu plików źródłowych w języku C i C++. Możliwości te mogą okazać się przydatne określając dodatkowe definicje makr lub opcje kompilacji. Użyj formatu: LOCAL_CPPFLAGS w celu określenia flag tylko dla języka C++.

Postaraj się nie zmieniać poziomu optymalizacji i debugowania w pliku Android.mk. System kompilacji może obsłużyć to ustawienie automatycznie za pomocą istotne informacje w pliku Application.mk. Dzięki temu funkcja do generowania przydatnych plików danych używanych podczas debugowania.

Dodatkowe ścieżki uwzględniania można określić, wpisując:

LOCAL_CFLAGS += -I<path>,

Do tego celu lepiej jednak używać parametru LOCAL_C_INCLUDES, ponieważ pozwala także używać ścieżek dostępnych do debugowania natywnego, ndk-gdb.

LOCAL_CPPFLAGS

Opcjonalny zestaw flag kompilatora, który będzie przekazywany podczas tworzenia źródła w C++ tylko pliki. Pojawią się po LOCAL_CFLAGS na stronie kompilatora wiersza poleceń. Użyj LOCAL_CFLAGS, aby określić flagi zarówno w języku C, jak i C++.

LOCAL_STATIC_LIBRARIES

Ta zmienna przechowuje listę modułów bibliotek statycznych, w których bieżąca który zależy od modułu.

Jeśli bieżący moduł jest biblioteką współdzieloną lub plikiem wykonywalnym, ta zmienna wymusza połączenie tych bibliotek z wynikowym plikiem binarnym.

Jeżeli bieżący moduł to biblioteka statyczna, zmienna ta wskazuje po prostu, w zależności od bieżącego modułu zależą również od wymienionych biblioteki.

LOCAL_SHARED_LIBRARIES

Ta zmienna to lista modułów bibliotek udostępnionych, w których ten moduł zależy od środowiska wykonawczego. Te informacje są niezbędne w momencie utworzenia linku i po to, aby umieścić odpowiednie informacje w wygenerowanym pliku.

LOCAL_WHOLE_STATIC_LIBRARIES

Ta zmienna jest wariantem zmiennej LOCAL_STATIC_LIBRARIES i wskazuje, że tag łączący powinien traktować powiązane moduły biblioteki jako całe archiwa. Dla: więcej informacji na temat całych archiwów znajdziesz w dokumentacji GNU ld Flaga --whole-archive.

Ta zmienna jest przydatna, gdy występują kołowe zależności między kilkoma bibliotek statycznych. Wykorzystasz tę zmienną do utworzenia udostępnionej biblioteki, wymuś dodanie przez system kompilacji wszystkich plików obiektów z bibliotek statycznych do końcowy plik binarny. Nie dotyczy to jednak plików wykonywalnych.

LOCAL_LDLIBS

Ta zmienna zawiera listę dodatkowych flag tagu łączącego, które można wykorzystać w tworzeniu udostępnianej biblioteki lub pliku wykonywalnego. Umożliwia stosowanie prefiksu -l do przekazywania nazwy poszczególnych bibliotek systemowych. Poniższy przykład pokazuje, tag łączący, aby wygenerować moduł łączący w czasie wczytywania z usługą /system/lib/libz.so godzina:

LOCAL_LDLIBS := -lz

Dla listy ujawnionych bibliotek systemowych, do których można się połączyć w tym pliku NDK Więcej informacji znajdziesz w artykule na temat natywnych interfejsów API.

Uwaga: jeśli zdefiniujesz tę zmienną dla biblioteki statycznej, system kompilacji zignoruje i ndk-build wyświetli ostrzeżenie.

LOCAL_LDFLAGS

Lista innych flag tagu łączącego, których system kompilacji używa przy tworzeniu udostępnianej biblioteki lub pliku wykonywalnego. Aby np. użyć tagu łączącego ld.bfd na stronie ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

Uwaga: jeśli zdefiniujesz tę zmienną dla biblioteki statycznej, system kompilacji zignoruje a następnie ndk-build wyświetli ostrzeżenie.

LOCAL_ALLOW_UNDEFINED_SYMBOLS

Domyślnie, gdy system kompilacji natrafi na niezdefiniowane odwołanie ale podczas próby utworzenia udostępnionego elementu wystąpi błąd niezdefiniowanego symbolu. Ten może pomóc w wykrywaniu błędów w kodzie źródłowym.

Aby wyłączyć sprawdzanie, ustaw tę zmienną na true. Pamiętaj, że to ustawienie może powoduje wczytanie biblioteki współdzielonej w czasie działania.

Uwaga: jeśli zdefiniujesz tę zmienną dla biblioteki statycznej, system kompilacji zignoruje a następnie ndk-build wyświetli ostrzeżenie.

TRYB LOKALNY

Domyślnie system kompilacji generuje docelowe pliki binarne ARM w trybie kciuka, gdzie każda instrukcja ma 16-bitową szerokość i jest powiązana z bibliotekami STL Katalog thumb/. Zdefiniowanie tej zmiennej jako arm wymusza na systemie kompilacji generowania plików obiektów modułu w 32-bitowym trybie arm. Przykład poniżej jak to zrobić:

LOCAL_ARM_MODE := arm

Możesz też polecić systemowi kompilacji tylko określone źródła w arm przez dodanie sufiksu .arm do nazw plików źródłowych. Na przykład parametr Z tego przykładu dowiesz się, że system kompilacji zawsze kompiluje bar.c w trybie ARM, ale aby utworzyć foo.c na podstawie wartości LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm

Uwaga: możesz też wymusić generowanie przez system kompilacji plików binarnych ARM przez ustawienie APP_OPTIM w pliku Application.mk do debug. Określanie: debug wymusza kompilację ARM, ponieważ debuger pęku narzędzi nie obsługuje kodu Thumb

LOCAL_ARM_NEON

Ta zmienna ma znaczenie tylko wtedy, gdy kierujesz reklamy na interfejs ABI armeabi-v7a. it pozwala na użycie wbudowanych kompilatora ARM Advanced SIMD (NEON) w językach C i C++ oraz instrukcje NEON w plikach Asembly.

Pamiętaj, że nie wszystkie procesory z procesorami ARMv7 obsługują rozszerzenia zestawu instrukcji NEON. Z tego powodu, aby móc bezpiecznie używać ten kod w czasie działania. Aby dowiedzieć się więcej, zapoznaj się z informacjami na temat wsparcia Neon i Funkcje procesora.

Możesz też użyć sufiksu .neon, aby określić, że system kompilacji kompilować tylko określone pliki źródłowe z obsługą NEON. W poniższym przykładzie system kompilacji kompiluje foo.c z obsługą kciuków i neonów, bar.c z obsługą kciuków i neonów obsługa kciuków i zoo.c z obsługą technologii ARM i NEON:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

Jeśli używasz obu sufiksów, .arm musi poprzedzać .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

Domyślnie system kompilacji kompiluje kod z ochroną ciągu znaków formatu. Wykonuję wymusza więc błąd kompilatora, jeśli w funkcji Funkcja w stylu printf. Ta ochrona jest domyślnie włączona, ale możesz ją wyłączyć go, ustawiając wartość tej zmiennej na true. Nie zalecamy tego bez ważnego powodu.

LOCAL_EXPORT_CFLAGS

Ta zmienna rejestruje zestaw flag kompilatora C/C++, które należy dodać do interfejsu LOCAL_CFLAGS. każdego innego modułu, który korzysta z niego. LOCAL_STATIC_LIBRARIES lub LOCAL_SHARED_LIBRARIES.

Przyjrzyjmy się np. następującej parze modułów: foo i bar, który zależy od foo:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_CFLAGS := -DFOO=1
include $(BUILD_STATIC_LIBRARY)


include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_CFLAGS := -DBAR=2
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

W tym przypadku system kompilacji przekazuje flagi -DFOO=1 i -DBAR=2 do kompilatora podczas tworzenia bar.c. Ten szablon dołącza też na początku wyeksportowanych flag do modułu LOCAL_CFLAGS, aby można je było łatwo zastąpić.

Dodatkowo relacja między modułami jest przechodni: jeśli zoo zależy od bar, która z kolei zależy od parametru foo, wtedy zoo również dziedziczy wszystkie flagi wyeksportowano z pliku foo.

System kompilacji nie używa wyeksportowanych flag podczas kompilowania lokalnego (np. tworząc moduł, którego flagi są eksportowane). W przykładzie nie przekazuje pliku -DFOO=1 do kompilatora podczas kompilacji foo/foo.c. Do lokalnie, używaj zamiast tego LOCAL_CFLAGS.

LOCAL_EXPORT_CPPFLAGS

Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS, ale tylko w przypadku flag C++.

LOCAL_EXPORT_C_INCLUDES

Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS, ale w przypadku C uwzględnij ścieżki. it jest przydatny, gdy na przykład bar.c musi zawierać nagłówki moduł foo.

LOCAL_EXPORT_LDFLAGS

Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS, ale w przypadku flag tagu łączącego.

LOCAL_EXPORT_LDLIBS

Ta zmienna jest taka sama jak LOCAL_EXPORT_CFLAGS i informuje system kompilacji, że i przekazywać do kompilatora nazwy konkretnych bibliotek systemowych. Dołącz -l na początku każdej wskazanej biblioteki.

Zwróć uwagę, że system kompilacji dołącza zaimportowane flagi tagu łączącego do wartości parametru zmiennej LOCAL_LDLIBS modułu. Wynika to ze sposobu działania elementów łączących Unix.

Ta zmienna jest zwykle przydatna, gdy moduł foo jest biblioteką statyczną i zawiera który zależy od biblioteki systemowej. Następnie możesz użyć LOCAL_EXPORT_LDLIBS do: wyeksportować zależność. Na przykład:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_LDLIBS := -llog
include $(BUILD_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

W tym przykładzie system kompilacji umieszcza -llog na końcu polecenia łączącego gdy tworzy libbar.so. W ten sposób powiadomisz tag łączący, że libbar.so w zależności od foo, zależy też od systemowej biblioteki logów.

LOCAL_SHORT_POLECENIA

Ustaw tę zmienną na true, jeśli Twój moduł ma bardzo dużą liczbę źródeł lub zależnych bibliotek statycznych bądź udostępnionych. Wymusza to w systemie kompilacji użyj składni @ w przypadku archiwów zawierających pośrednie pliki obiektów lub do połączeń biblioteki.

Ta funkcja może być przydatna w systemie Windows, w którym wiersz poleceń akceptuje maksimum składające się z zaledwie 8191 znaków, co może być zbyt małe w przypadku złożonych projektów. Dodatkowo wpływa na kompilację poszczególnych plików źródłowych, przez co flagi także w plikach list.

Pamiętaj, że każda wartość inna niż true zostanie przywrócone do działania domyślnego. Ty można również zdefiniować zasadę APP_SHORT_COMMANDS w pliku Application.mk, aby wymusić w obrębie wszystkich modułów w projekcie.

Nie zalecamy domyślnego włączania tej funkcji, ponieważ powoduje to, że kompilacja wolniej.

LOCAL_THIN_ARCHIVE

Podczas tworzenia bibliotek statycznych ustaw tę zmienną na true. Jeśli to zrobisz, wygenerować małe archiwum, czyli plik biblioteki, który nie zawiera plików obiektów, ale zamiast tego tworzyć ścieżki do rzeczywistych obiektów, które normalnie zawierają.

Pozwala to zmniejszyć rozmiar danych wyjściowych kompilacji. Wadą jest to, takich bibliotek nie można przenieść do innej lokalizacji (żadnych zawartych w nich ścieżek) są względne).

Prawidłowe wartości to true, false lub puste. Wartość domyślną można ustawić w Application.mk za pomocą zmiennej APP_THIN_ARCHIVE.

Uwaga: ta zasada jest ignorowana w przypadku niestatycznych modułów biblioteki lub gotowej biblioteki statycznej. tylko tych.

LOCAL_FILTER_ASM

Zdefiniuj tę zmienną jako polecenie powłoki, którego system kompilacji będzie używać do filtrowania pliki montażowe wyodrębnione lub wygenerowane z plików wskazanych przez Ciebie LOCAL_SRC_FILES Zdefiniowanie tej zmiennej powoduje następujące konsekwencje:

1. System kompilacji generuje tymczasowy plik instalacyjny z dowolnego źródła w języku C lub C++. zamiast kompilować w pliku obiektowym.
2. System kompilacji wykonuje polecenie powłoki w dokumencie LOCAL_FILTER_ASM na dowolnym tymczasowy plik montażowy oraz dowolny plik montażowy na liście LOCAL_SRC_FILES. w ten sposób i w ten sposób wygenerujemy kolejny tymczasowy plik asemblera.
3. System kompilacji kompiluje te przefiltrowane pliki zestawu do pliku obiektu.

Na przykład:

LOCAL_SRC_FILES  := foo.c bar.S
LOCAL_FILTER_ASM :=

foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o

„1” odpowiada kompilatorowi, „2” i „3” do asekuratora. Filtr musi być samodzielnym poleceniem powłoki, które przyjmuje nazwę danych wejściowych jako pierwszego argumentu, a nazwa pliku wyjściowego jako drugiego. Na przykład:

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S

Makra funkcji udostępnione przez NDK

W tej sekcji opisano dostępne w programie NDK makra funkcji programu GNU Make. Używaj $(call <function>), aby je ocenić; zwracają informacje tekstowe.

moj-katalog

To makro zwraca ścieżkę ostatniego uwzględnionego pliku Makefile, który zwykle jest w bieżącym katalogu użytkownika Android.mk. Funkcja my-dir jest przydatna do określenia LOCAL_PATH na początku pliku Android.mk. Na przykład:

LOCAL_PATH := $(call my-dir)

Ze względu na sposób działania GNU Make makro tak naprawdę zwraca ścieżkę ostatni plik Makefile dołączonego przez system kompilacji podczas analizy skryptów kompilacji. Dla: z tego powodu, nie należy wywoływać my-dir po dołączeniu innego pliku.

Na przykład:

LOCAL_PATH := $(call my-dir)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(call my-dir)

# ... declare another module

Problem polega na tym, że drugie wywołanie funkcji my-dir określa LOCAL_PATH jako $PATH/foo zamiast $PATH, bo tam właśnie ostatnio szpiczastej.

Aby uniknąć tego problemu, umieść dodatkowe słowa ujęte po wszystkich pozostałych elementach. w pliku Android.mk. Na przykład:

LOCAL_PATH := $(call my-dir)

# ... declare one module

LOCAL_PATH := $(call my-dir)

# ... declare another module

# extra includes at the end of the Android.mk file
include $(LOCAL_PATH)/foo/Android.mk

Jeśli nie możesz tak skonstruować struktury pliku, zapisz wartość atrybutu pierwsze wywołanie my-dir do innej zmiennej. Na przykład:

MY_LOCAL_PATH := $(call my-dir)

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare another module

all-subdir-makefiles

Zwraca listę plików Android.mk znajdujących się we wszystkich podkatalogach funkcji bieżąca ścieżka (my-dir).

Za pomocą tej funkcji możesz umieścić głęboko zagnieżdżone hierarchie katalogów źródłowych w w systemie kompilacji. Domyślnie NDK szuka tylko plików w katalogu zawierający plik Android.mk.

this-makefile

Zwraca ścieżkę bieżącego pliku Makefile (z którego system kompilacji wywołał funkcję ).

nadrzędny-makefile,

Zwraca ścieżkę nadrzędnego pliku Makefile w drzewie uwzględniania (ścieżka klucza programu Makefile zawierającego bieżący plik).

plik magistrali

Zwraca ścieżkę pliku Makefile nadrzędnego w drzewie uwzględniania (ścieżka w pliku Makefile dołączonego do bieżącego).

importuj moduł

Funkcja, która umożliwia znalezienie i dołączenie pliku Android.mk modułu przez nazwa modułu. Typowy przykład jest następujący:

$(call import-module,<name>)

W tym przykładzie system kompilacji szuka modułu oznaczonego tagiem <name> lista katalogów, do których odwołuje się środowisko NDK_MODULE_PATH do zmiennych i automatycznie dołącza jej plik Android.mk.