Исходный код андроид что это такое

Android от А до Я: Что такое открытый исходный код и открытое ПО (open source)

Открытое программное обеспечение (open-source software) предназначено для свободного доступа к исходному коду для всех желающих. Существуют разные лицензии с разными условиями использования от GPL (GNU General Public License) и до более лояльной Apache License. Первая разрешает бесплатное распространение при условии использования этой же лицензии для последующей продукции. Вторая не требует обязательного распространения готового продукта и открытости исходного кода. Android использует обе. Внутри продолжение рассказал об открытом исходном коде и открытом ПО.

Ядро Linux, которое используется в ОС, попадает под действие GPL. Это означает, что все изменения исходного кода должны быть доступны общественности после официального выхода софта. На практике это должно выглядеть следующим образом: такие производители как HTC, Samsung, Motorola, выпуская новое устройство, обязаны делать открытый доступ к исходному коду с моменты выпуска этого устройства. В большинстве своем производители железа немного затягивают с этим.

Исходный код для ОС Android как правило попадает под действие Apache License. Каждый может загрузить исходный код и изменить его, при этом нет необходимости делать код доступным для всех. По этой причине Android не могут изменить или усовершенствовать HTC Sense или MotoBlur. Несмотря на то, что подобная ситуация не нравится многим пользователям, она не может быть изменена в силу коммерческих причин. Если бы производители делали доступными все свои секреты, то отпала бы финансовая причина создавать различные инновации для опережения соперников в конкурентной борьбе. Таким образом, использование более лояльной лицензии является полностью оправданным. Выпуск новых устройств регулярно подтверждает это.

Источник

Модификация исходного кода android-приложения с использованием apk-файла

Так уж получилось, что приложение для чтения комиксов и манги, которое я использую на своем android-смартфоне, после обновления стало показывать рекламу в конце каждой главы комикса. Данное приложение пару лет назад было доступно на Google Play (платная версия которого и была мной куплена), но было удалено в силу «нарушения авторских прав», после чего ушло в подполье и стало распространятся через сайт разработчика. Увы, достойных альтернатив этому приложению на android и iOS я не нашел, но и смотреть рекламу особо не было желания, тем более я уже покупал версию без рекламы. Сам разработчик почему-то не сделал возможности отключить ее, а на просьбы добавить такую возможность не отозвался. Поэтому пришлось искать альтернативные методы ее отключения. Первое, что пришло в голову, это то, что android-приложения пишутся на java, а значит есть вероятность, что автор не обфусцировал свое приложение и его можно попытаться декомпилировать. Немного подумав, я приступил к работе.

Для начала был загружен сам apk-файл приложения. Затем недолгий поиск по интернету привел меня на сайт http://www.decompileandroid.com/. С его помощью можно было загрузить apk-файл с приложением и на выходе получить набор исходников. Увы, декомпиляция в java-классы происходит не совсем идеально и поэтому восстановить полностью сам проект приложения в IDE(Idea) у меня не получилось, но это позволило проанализировать саму структуру проекта и разобраться как он примерно работает. После проведения анализа, было найдено два перспективных метода в классе BaseReaderFragment.java – placeAdViewIfNeeded и removeAdViewIfNeeded.

Код метода placeAdViewIfNeeded:

Самое простое, что пришло на ум после чтения кода, это убрать все лишнее, и оставить лишь вызов return;

Но, как уже было сказано, даже если бы я изменил в java-классе что-либо, я бы не смог в итоге скомпилировать приложение в IDE. Поэтому пришлось искать альтернативу. Оказалось, что smali-файлы, которые создаются в процессе декомпиляции, позволяют также после внесения нужных изменений, вновь собрать модифицированное приложение. Увы, сайт, что был приведен выше, позволял лишь получать исходники, но не собирать новые. Поэтому пришлось искать способы сделать это самостоятельно.
Была найдена утилита ApkTools, которая позволяла декомпилировать и компилировать apk-файлы. Кроме того, потребовалась утилита aapt.exe, которая была взята мной из стандартного SDK под андроид в папке android-sdk\build-tools\20.0.0.

Для удобства вызова утилиты из под windows был создан скрипт apktool.bat:

Для декомпиляции приложения были выполнены команды:

После чего, в полученных исходниках был найден файл BaseReaderFragment.smali и нужные нам методы были изменены следующим образом:

Далее пришла очередь сборки apk-файла из исходников.

Сделать это можно cледующей командой:

Но это еще не все. Чтобы приложение можно было установить, его нужно было подписать цифровой подписью. Самый простой способ сделать это – это скачать архив в котором находится утилита для подписи приложений и цифровые сертификаты к ней.

Распаковываем архив, выполняем команду:

Полученный apk-файл можно загружать на телефон, чтобы проверить наше модифицированное приложение. Однако в процессе тестирования изменений оказалось, что объявления больше не показываются, однако сама страница для их показа создается, что не очень приятно. Снова был проанализирован код приложения, найден класс BaseSeamlessReaderFragment, а в нем метод appendPages.

В нем было видно, что строчка:

создает дополнительную страницу, помимо тех, что есть в главе манги, с параметром, отвечающим за показ объявлений. Было решено удалить эту строчку и посмотреть результат. Снова заглядываем в аналогичный smali-файл(BaseSeamlessReaderFragment$4) и удаляем строчку:

Снова проводим сборку apk-файла из исходников и подписываем наше приложение. После установки и тестирования приложения экран с рекламой окончательно исчез, что и было конечной целью.

Данный пример показывает, что в случае необходимости можно довольно просто и быстро модифицировать уже существующие android-приложения, чтобы добавить в них недостающий функционал или наоборот удалить некоторые нежелательные возможности в тех ситуациях, когда доступа к исходникам нет. Надеюсь он поможет людям, которые попали в похожую ситуацию и не хотят мирится с ней, найти решение проблемы.

Источник

Беседка №97. Открытый код спасёт Android

Илья Субботин

Мнение, диаметрально противоположное высказанному в прошлой Беседке. Так ли всё печально в ситуации с открытым кодом?

Адриан Кингсли-Хьюз в рамках своего материала на ресурсе ZDNet поделился интересными взглядами по поводу Android, назвав фрагментацию главной проблемой ОС. Однако, сам факт, является ли она на самом деле проблемой, зависит от того, кому адресован этот тезис. Среднестатистические пользователи не испытывают неудобств из-за фрагментации, т.к. Google решила проблему, разделив операционную систему и приложения / сервисы.

Пользователи даже устаревших версий Android могут спокойно получать обновления сервисов Google и приложений. На моём Nexus 7 2012 года и устройствах Samsung Galaxy установлены новейшие версии приложений и игр, включая Netflix, Plex, YouTube и HBO Now. Версия приложений на упомянутых устройствах совпадает с таковой на моих новинках — Pixel C и Nexus 6P. Подобная ситуация бросает тень на iOS, где новейшие версии приложений недоступны для сравнительно более старых смартфонов и планшетов, делая эти устройства менее безопасными и менее практичными.

Кингсли-Хьюз задаётся вопросом, что можно сделать для устранения проблемы, и выдвигает предположение о том, что возможным решением станет превращение Android в систему с закрытым исходным кодом. Я считаю такой подход неправильным, о причинах далее.

Открытый код — это модель разработки

Люди склонны неправильно интерпретировать понятие «открытый код». Оно обозначает модель разработки ПО, а не способ его развертывания на устройства и не бизнес-модель. Разработка Android и «выкатывание» обновлений на устройствах — совершенно разные вещи.

Открытый код обеспечивает нулевую фрагментацию

Chrome OS является операционной системой с открытым кодом, как и Android. Но с самого начала Google использовала другой механизм для «доставки» обновлений на устройства с Chrome OS. Был использован подход с промежуточным образом: на устройство устанавливались два образа операционной системы, один из которых обеспечивал работу систему, второй же просто находился «на фоне». При наличии обновления оно замещало неактивный и устаревший образ ОС. После перезагрузки устройство переключалось на новую версию. Таким образом, устройство всегда имело актуальную версию ПО без каких-либо усилий со стороны пользователя.

Ту же модель использует Core OS, дистрибутив на базе Linux для серверов. Браузер Chrome имеет в своей основе открытый код, который также обновляется. Подобным образом обновляются Mozilla Firefox и Thunderbird. Используя ПО с открытым кодом, вы можете осуществлять планомерное обновление устройств.

«Закрытое» ПО не поможет

Неоправданным и необоснованным выглядит и убеждение о магической способности ПО с закрытыми исходниками справляться с фрагментацией. Примером максимально проприетарного ПО является Windows, фрагментация в случае этой ОС носит ужасающий характер: Windows XP — 10%, Windows 7 — 49%, Windows 8 — 2.45%, Windows 8.1 — 8%, Windows 10 — 19%. Хуже всего то, что 95% процентов банкоматов по всему миру до сих пор работают на Windows XP, что говорит отнюдь не об их безопасности. Что касается фрагментации Internet Explorer, то и тут всё далеко не радужно, несмотря на проприетарный характер продукта. Даже Apple, имея полный контроль над аппаратным и программным обеспечением своих продуктов, испытывает трудности при обновлении iOS и macOS.

Хаос в Linux.

В своём сравнении Android с Linux автор выдвинул следующее мнение:

..На примере Android можно на практике увидеть, в какой хаос превратилась бы Linux, если бы она пользовалась повсеместной популярностью у производителей аппаратного обеспечения. Кто-то где-то должен взять управление ситуацией на себя и поставить интересы платформы выше доли рынка и прибыли…

Автор удивится, но Linux на самом деле пользуется популярностью у OEM-производителей «железа». Linux имеет значительный вес во всём, кроме версий для ПК. Всё же, расстановка сил понемногу меняется, по мере того, как Chrome OS активно отъедает долю у Microsoft. Популярность Linux дошла до того, что Microsoft разработала операционную систему, основанную на Linux и предназначенную для работы с Azure. Не будем забывать, что доля компьютеров на базе Linux для Azure выросла с 25 до 33 процентов. Так что Linux успешно развивается даже на «территории» Microsoft. На базе Linux работает почти всё: суперкомпьютеры, роутеры, принтеры, Comcast X1, Tesla и т.д.

Несмотря на распространенность Linux в различных отраслях и всю противоречивость этого факта мнению Кингсли-Хьюза, Linux на самом деле не мешало бы привести в порядок. Благодаря открытой модели разработки, самые активные представители сообщества по разработке ядра Linux продолжают выпускать заплатки для уязвимостей ОС, выпуская обновление раз в два месяца. До сих пор можно найти системы на базе устаревших и неподдерживаемых версий Linux. В интервью с Грегом Кроа-Хартманом, ведущим разработчиком ядра Linux, им было высказано мнение о том, что компаниям необходимо создать механизм для поддержки обновления систем до актуальной версии. Он также высоко оценил способ обновления Chrome OS и Core OS.

Повторюсь, открытый код никак не связан с обновлениями ПО. Совершенно разные области.

Что является причиной фрагментации?

Корень проблемы — в желании OEM-производителей дифференцировать себя от конкурентов путём использования собственных тем оформления и ПО. Операторы связи используют множество предзустановленных программ как дополнительный источник дохода. Процесс обновления таких устройств тормозится: производителям и операторам необходимо протестировать свой «фуфлософт» на предмет его стабильной работы с новой версией Android. А раз обновлению до новой версии ОС не способствует финансовый стимул, то они его откладывают. Они зарабатывают на продажи устройств, а не на их обновлении. Был бы финансовый стимул — были бы и своевременные обновления. Так что если Google хочет покончить с проблемой фрагментации Android, то ему необходимо найти способ исключить этих игроков из процесса обновлений, что Google и собирается сделать.

Совсем не обязательно «закрывать» Android

Хоть в Google и решили проблему обновления приложений на устройствах с устаревшими версиями ПО в обход производителей и операторов, сейчас в компании работают над способом обновления Android, подобным таковому в Chrome OS. В рамках релиза новой версии Android Nougat обновление по мере доступности будет загружаться на устройство подобно образу в Chrome OS и после перезапуска системы уже будет работать без сучка и задоринки.

Вывод

В конечном итоге, открытый характер системы на самом деле лучше «приспособлен» для решения проблемы фрагментации, чем любое проприетарное ПО в мире. Перед тем, как размышлять о превращении Android в подобный софт, стоит взглянуть на ужас, творящийся с фрагментацией Windows и IE. Открытый код не убивает Android: ОС процветает и продолжает теснить iOS и Windows.

Вполне адекватный и обоснованный контраргумент. Как мы можем видеть, понемногу проблема с фрагментацией по версиям Android постепенно сглаживается, да и такого беспокойства, как раньше, проблема не вызывает. Новый механизм обновлений? Ну почему бы и нет, если он на самом деле избавит Android от фрагментации и устранит, то поклонники Android будут только за. Понравился пассаж про предустановленное ПО, у некоторых производителей ситуация с подобными приложениями переходит все рамки разумного, причем грешат этим вполне крупные игроки. Итак, два мнения об открытом коде: какое ближе вам? Считаете ли вы фрагментацию всё еще актуальной проблемой?

Источник

Русские Блоги

Подробное введение в исходный код системы Android Система сборки

Предисловие

Недавно я занимаюсь разработкой системы, и многие знания нужно обобщить и разобрать. Недавно, когда я писал файлы Makefile, я нашел несколько статей в Интернете и обнаружил, что эта статья очень ценна для начала работы.«Подробное введение в исходный код системы Android. Система сборки»Большая часть содержания статьи перепечатана в оригинальном тексте. Я собираюсь отсортировать его и разместить в своем блоге для удобства.

1. Файл Android.mk, содержащий C

В предыдущей ранней версии мы загрузимNDKКогда обычно бывает одинhello-jniЭтот вариант использования удобен для изучения и понимания самостоятельно. Поскольку мы не можем его найти, я опубликую здесь содержание.

Пояснение к первой строке

Эта переменная указывает расположение исходного файла в дереве разработки. Здесь создайте макрос-функцию, предоставляемую системой my-dir Вернется в текущий каталог ( Android.mk Путь к каталогу, в котором находится сам файл.
LOCAL_PATH: это системная переменная, установленная системой сборки. Чтобы скомпилировать модуль, просто установите эти переменные по мере необходимости перед компиляцией, а затем выполните компиляцию.

Часто используемые системные переменные компиляции

имя переменной	Описание
LOCAL_SRC_FILES	Все файлы исходного кода, содержащиеся в текущем модуле.
LOCAL_MODULE	Имя текущего модуля. Это имя должно быть уникальным. По этому имени указываются зависимости между модулями.
LOCAL_C_INCLUDES	Путь к файлу заголовка, требуемый языком C или C ++.
LOCAL_STATIC_LIBRARIES	Имя библиотеки, которая нужна текущему модулю при статической компоновке.
LOCAL_SHARED_LIBRARIES	Имя динамической библиотеки, от которой зависит текущий модуль во время выполнения.
LOCAL_CFLAGS	Дополнительные параметры компиляции, предоставляемые компилятору C / C ++.
LOCAL_JAVA_LIBRARIES	Общая библиотека Java, от которой зависит текущий модуль.
LOCAL_STATIC_JAVA_LIBRARIES	Статическая библиотека Java, от которой зависит текущий модуль.
LOCAL_PACKAGE_NAME	Имя текущего приложения APK.
LOCAL_CERTIFICATE	Имя сертификата, которым подписано текущее приложение.

Собираюсь поднять отдельно LOCAL_MODULE_TAGS , Что означает метку, содержащуюся в текущем модуле. Значение тега может быть отладочным, английским, пользовательским, разработанным или необязательным. Среди них необязательная метка по умолчанию. Метки предназначены для использования скомпилированными типами. Разные типы компиляции будут устанавливать модули с разными тегами, так что же представляют значения этих тегов?

название	Описание
eng	Тип по умолчанию, этот тип компиляции подходит для фазы разработки. Если выбран этот тип, результатом компиляции будет: Установить модули с тегами eng, debug, user и development Установить все модули, не относящиеся к APK, без тегов Установить все модули APK, указанные в файле определения продукта
user	Этот тип компиляции подходит для стадии финального релиза. Если выбран этот тип, результатом компиляции будет: Установить все модули с пользовательскими тегами Установить все не-APK модули без тегов Установить все модули APK, указанные в файле определения продукта, и теги модулей APK будут проигнорированы
userdebug	Этот тип компиляции подходит для фазы отладки. Этот тип такой же, как и у пользователя, за исключением: Будут установлены модули, содержащие отладочные теги. Скомпилированная система имеет root-доступ.

Пояснение ко второй строке

CLEAR_VARS Переменная указывает на специальный файл GNU Makefile, который очистит многие LOCAL_XXX Переменные, например LOCAL_MODULE 、 LOCAL_SRC_FILES с участием LOCAL_STATIC_LIBRARIES , Обратите внимание, что GNU Makefile не очищает LOCAL_PATH , Эта переменная должна сохранять свое значение, потому что система анализирует все файлы управления сборкой в ​​одной среде выполнения GNU Make (все переменные в ней являются глобальными).

Перед описанием каждого модуля эту переменную необходимо объявить (повторно объявить).

Третий ряд

Вернемся к вышесказанному и посмотрим на определение LOCAL_MODULE.LOCAL_MODULE Модули должны быть определены для представления каждого модуля в Android.mk. Имя должно быть уникальным и не содержать пробелов. Система сборки автоматически добавит соответствующий префикс и суффикс. Например, foo Чтобы создать динамическую библиотеку, сгенерируйте libfoo.so , Но обратите внимание: если имя модуля установлено как: libfoo , Затем сгенерируйте libfoo.so .. Больше никаких префиксов.Зависимости между модулями обозначаются этим именем.

Четвертый ряд

Это предложение означает, что в исходном пути моего проекта есть только один файл, и это файл hello-jni.c в каталоге, где находится мой MK-файл.

Пятая строка

Последняя строка помогает системе соединить все вместе. BUILD_SHARED_LIBRARY Переменная указывает на сценарий GNU Makefile, который используется для сбора LOCAL_XXX Вся информация определена в переменной. Этот сценарий определяет, что строить и как это строить.

2. Файл Android.mk без C

Фактически, приведенный выше метод mk добавляет файлы jni в дерево исходных текстов. Давайте сначала изучим файл Android.mk, который не содержит файлов C, который является отображением первой написанной нами программы helloworld в дереве исходных текстов Android. Разберем содержимое Android.mk.

LOCAL_SRC_FILES := $(call all-subdir-java-files)

Мы видим, что формулировка здесь отличается от формулировки вышеупомянутого C. All-subdir-java-files представляет все java-файлы в подкаталоге, так что, если имеется несколько файлов C? Некоторые удобные функции также определены в системе сборки для использования в Android.mk, а именно:

• $ (call my-dir): получить текущий путь к папке.
• $ (call all-java-files-under,): получить все файлы Java в указанном каталоге.
• $ (call all-c-files-under,): получить все языковые файлы C в указанном каталоге.
• $ (call> all-Iaidl-files-under,): получить все файлы AIDL в указанном каталоге.
• $ (call> all-makefiles-under,): получить все Make-файлы в указанном каталоге.
• $ (call intermediate-dir-for ,, ,, ): получить путь к целевой папке для вывода сборки.

Третий ряд

LOCAL_PACKAGE_NAME: = LocalPackage // имя приложения

Это относится к имени текущего приложения APK. Это не то же самое, что LOCAL_MODULE. Оно не уникально. Оно эквивалентно имени appName в файле манифеста Manifest.xml.

Четвертый ряд

LOCAL_CERTIFICATE: = platform // Имя сертификата, подписывающего текущее приложение.

Это имя соответствует системной подписи, перед которой система содержит четыре типа подписи.

Тип подписи

• testkey
• media
• platform
• shared

Для четырех указанных выше ключей вы можете увидеть соответствующие ключи в исходном коде / build / target / product / security, где shared.pk8 представляет собой закрытый ключ, а открытый ключ shared.x509.pem должен отображаться парами. Среди них testkey является ключом подписи по умолчанию при компиляции Android. Если значение LOCAL_CERTIFICATE не установлено в android.mk apk в системе, testkey используется по умолчанию. И если для него установлено значение: LOCAL_CERTIFICATE: = platform, это означает использование платформы для подписи. В этом случае этот apk имеет ту же подпись, что и система, потому что подпись уровня системы также подписывается платформой, поэтому используйте android:sharedUserId=»android.uid.system» Только полезно!

Пятая строка

Исходный код Android содержит множество модулей, и есть много типов модулей, таких как: библиотеки Java, библиотеки C / C ++, приложения APK и исполняемые файлы. Кроме того, библиотеки Java или C / C ++ также можно разделить на статические или динамические библиотеки или исполняемые файлы, которые могут зависеть от устройства («устройство» в этой статье относится к устройству, на котором будет установлена ​​система Android, например, определенной модели мобильного телефона. Или планшет) также может быть направлен на хост («хост» в этой статье относится к машине, которая разрабатывает систему Android, например ПК с операционной системой Ubuntu, iMac или Macbook с MacOS). Шаги и методы компиляции различных типов модулей различны. Чтобы иметь возможность выполнять компиляцию различных типов модулей последовательно и удобно, вconfig.mk
Многие константы определены в . Каждая из этих констант описывает метод компиляции модуля определенного типа. Эти константы включают

• BUILD_HOST_STATIC_LIBRARY
• BUILD_HOST_SHARED_LIBRARY
• BUILD_SHARED_LIBRARY
• BUILD_EXECUTABLE
• BUILD_PACKAGE BUILD_PREBUILT
• BUILD_MULTI_PREBUILT
• BUILD_JAVA_LIBRARY
• BUILD_HOST_JAVA_LIBRARY

По названию можно угадать тип модуля, соответствующий каждой переменной. (В файле Android.mk модуля, если здесь указана соответствующая константа, может быть выполнена компиляция модуля соответствующего типа.

Значения этих констант представляют собой путь к другому Make-файлу, а подробный метод компиляции определяется в соответствующем Make-файле. Эти константы взаимно однозначно соответствуют Make-файлу, и соответствующие правила также очень просты: имя константы — это имя файла Make-файла без суффикса, все они изменяются на верхний регистр, а затем с префиксом «BUILD_». Например постоянная BUILD_HOST_PREBUILT Файл, соответствующий значению, — host_prebuilt.mk. Ниже приведены другие достойные соответствующие файлы mk.

имя файла	Описание
host_static_library.mk	Определяет, как скомпилировать статическую библиотеку на хосте
host_shared_library.mk	Определяет, как компилировать разделяемые библиотеки на хосте
static_library.mk	Определяет, как скомпилировать статическую библиотеку на устройстве
shared_library.mk	Определяет, как компилировать разделяемые библиотеки на устройстве
executable.mk	Определяет, как компилировать исполняемые файлы на устройстве
host_executable.mk	Определяет, как компилировать исполняемые файлы на устройстве
package.mk	Определите, как компилировать файлы APK
prebuilt.mk	Определите, как обрабатывать скомпилированный файл (например, пакет jar)
multi_prebuilt.mk	Определите, как поступать с одним или несколькими скомпилированными файлами, реализация которых зависит от файла prebuilt.mk.
host_prebuilt.mk	Обработка скомпилированных файлов, используемых на одном или нескольких хостах. Реализация этого файла зависит от файла multi_prebuilt.mk.
java_library.mk	Определите, как компилировать общие библиотеки Java на устройстве
static_java_library.mk	Определите, как скомпилировать статическую библиотеку Java на устройстве
host_java_library.mk	Определяет, как скомпилировать общие библиотеки Java на хосте

Зависимость

3. Переменные и макросы

Система сборки предоставляет множество Android.mk Переменные в файле. Многие из этих переменных были скопированы заранее. Остальные переменные назначаете вы.

• Имена, начинающиеся с LOCAL_, например LOCAL_MODULE.
• Имена, начинающиеся с PRIVATE_, NDK_ или APP. Система сборки использует эти переменные внутри себя.
• Имя в нижнем регистре, например my-dir. Система сборки также использует эти переменные внутри.
  Если вам нужно Android.mk Определите свои собственные переменные в файле, рекомендуется добавлять перед именем MY_ 。

Включить переменные, определенные NDK

В этом разделе обсуждается анализ системы сборки Android.mk GNU Make переменные, определенные перед файлом. В некоторых случаях NDK может решить Android.mk File, каждый раз используя разные определения некоторых переменных.

CLEAR_VARS
Сценарий сборки, на который указывает эта переменная, используется для отмены определения почти всех переменных LOCAL_XXX, перечисленных в разделе «Переменные, определенные разработчиком» ниже. Перед описанием нового модуля используйте эту переменную, чтобы включить этот сценарий. Синтаксис использования этой переменной:

BUILD_SHARED_LIBRARY
Сценарий сборки, на который указывает эта переменная, используется для сбора всей необходимой информации о модуле, который вы указали в переменной LOCAL_XXX, и определения того, как создать целевую общую библиотеку на основе перечисленных исходных файлов. Обратите внимание, что для использования этого сценария необходимо, чтобы у вас были как минимум назначены значения для LOCAL_MODULE и LOCAL_SRC_FILES (для получения дополнительной информации об этих переменных см. Переменные описания модуля).
Синтаксис использования этой переменной:

Переменные общей библиотеки заставляют систему сборки создавать файлы библиотеки с расширением .so.

PREBUILT_SHARED_LIBRARY
указывает на сценарий сборки, используемый для указания предварительно созданной общей библиотеки. В отличие от BUILD_SHARED_LIBRARY и BUILD_STATIC_LIBRARY, значение LOCAL_SRC_FILES здесь не может быть исходным файлом, а должно быть единственным путем к предварительно созданной разделяемой библиотеке, такой как foo / libfoo.so. Синтаксис использования этой переменной:

Вы также можете использовать переменную LOCAL_PREBUILTS для ссылки на предварительно созданную библиотеку в другом модуле. Для получения дополнительной информации об использовании готовых библиотек см.Используйте готовые библиотеки。

PREBUILT_STATIC_LIBRARY
То же, что и PREBUILT_SHARED_LIBRARY, но используется для предварительно созданных статических библиотек. Для получения дополнительной информации об использовании готовых библиотек см.Используйте готовые библиотеки。

Источник