Современный способ создания приложения для Android из исходного кода в среде AOSP
programming android android-app-development

Современный способ создания приложения для Android из исходного кода в среде AOSP

29 апреля 2023 г.

Это будет мой первый пост здесь, я начну с первых шагов, которые обычно делаются в AOSP; скомпилируйте приложение Android в среде AOSP как системное приложение.

Эта тема также обширна, учитывая большое количество изменений, которые вы можете внести в нее, документы, которыми я делюсь, будут продолжать развиваться. В рамках этого документа я не буду рассматривать готовый APK-файл.

Цели

Скомпилируйте приложение для Android из исходного кода в дереве AOSP и включите его как часть образа ОС, например системное приложение, которое находится в каталоге, например: /system/app/SampleSystemApp

Похожие пути, такие как /system/priv-app, или разделы, такие как system_ext, product, odm, vendor также можно сделать аналогичным образом. Это во многом зависит от ваших требований, какой раздел вы хотите использовать, если вы передаете xTS - если требуется.

Окружающая среда:

ОС — AOSP Android 13 — android-13.0.0_r37

Целевой продукт: только 64-разрядный эмулятор — sdk_phone64_x86_64-userdebug

Реализация:

1. Добавьте исходный код приложения в дерево aosp.

Предположим, что у нас есть пример приложения с именем SampleSystemApp. Большинство приложений в основном настраиваются в разделе $(SRC_ROOT_DIR)packagesapps Предположим, что это выглядит примерно так:

packages
    apps
        SampleSystemApp

А здесь у нас есть обычная исходная структура приложения для Android, как у обычного приложения из Android Studio.

Убедитесь, что в AndroidManifest.xml есть атрибут package, определенный в теге <manifest>, иначе aapt не сможет выполнить компиляцию.

2. Создайте файл Android.bp для системы сборки (скоро).

Ссылки также можно брать из любого стандартного приложения AOSP. Файлы Android.bp на основе Blueprint будут знакомы разработчикам, которые раньше использовали Bazel.

Пример файла Android.bp для нашего приложения. Это приложение написано на Kotlin, с компилируемым и целевым sdk как 33, а min sdk как 28. Оно будет иметь зависимости от определенных библиотек (те, которые я использовал, уже являются частью дерева AOSP). Если вы хотите использовать внутренние SystemAPI, вы можете указать platform_apis: true и подписать это приложение сертификатом платформы, используя запись certificate: "platform" в Android.bp

package {
    // See: http://go/android-license-faq
    default_applicable_licenses: ["Android-Apache-2.0"],
}

android_app {
    name: "SampleSystemApp",
    srcs: [
        "app/src/main/java/**/*.kt",
    ],
    resource_dirs: [
        "app/src/main/res",
    ],
    manifest: "app/src/main/AndroidManifest.xml",
    sdk_version: "33",
    min_sdk_version: "28",
    target_sdk_version: "33",
    static_libs: [
        "com.google.android.material_material",
        "androidx.core_core",
        "androidx.preference_preference",
        "androidx.lifecycle_lifecycle-extensions",
        "androidx-constraintlayout_constraintlayout"
    ]
}

Чтобы сделать его привилегированным приложением system/priv-app, добавьте атрибут привилегированный: true.

Для разных разделов можно использовать разные атрибуты, например.

(a.) system_ext_specific (б.) product_specific (c.) device_specific (г.) soc_specific

Дополнительную документацию по модулям и атрибутам Soong можно найти в Android CI — здесь.

3. Теперь включите этот модуль в PRODUCT_PACKAGES.

После обеда вы можете вручную протестировать компиляцию через make name. Замените имя на имя модуля, которое вы определили в Android.bp. Здесь это будет SampleSystemApp.

Чтобы включить его в сборку, вам нужно добавить его в PRODUCT_PACKAGES.

Поскольку мы создаем цель emulator (goldfish), мы должны добавить ее в файл .mk в device/generic/goldfish. каталог. Здесь мы будем использовать emulator64_x86_64/device.mk:

PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST += 
    system/app/SampleSystemApp/%

PRODUCT_PACKAGES += SampleSystemApp

Флаг PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST требуется для пути system и system_ext из Android 11 (API 30) и выше — ссылка. Он вам не нужен, если модуль, который вы создаете, должен быть частью разделов odm, vendor или product.

4. Проверка — вывод сборки и работающий эмулятор.

А. Убедитесь, что он добавлен в образ системы, создав весь образ эмулятора.

сделать -j$(nproc --all)

Б. Проверьте следующие пути:

(a) – out/target/product/emulator64_x86_64/system/app/

(b) — out/target/product/emulator64_x86_64/installed-files.json

Здесь вы должны увидеть файлы/пути для вашего приложения.

C. Чистая загрузка эмулятора с разрешительным SE Linux

emulator -no-snapshot -selinux disabled &

Подождите, пока эмулятор загрузится в домашнее приложение, и проверьте приложение на экране запуска панели приложений.

Или программно через пакеты adb shell pm list, где вы увидите имя пакета вашего приложения.

D. Протестируйте свое приложение и исправьте ошибки, если таковые имеются.

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE