Build process in android

Android Build Process

There are a lot of steps involved in android build process. We will discuss them one by one. But before jumping to the explanation lets take a look at the below diagram first where I have tried to put all the steps of build process together.

AAPT Tool

AAPT stands for android assets packaging tool. This tool comes with the Android SDK and present in $ANDROID_HOME/platform-tools/ . It takes all the resources present in the res/ directory and compiles them. It generates a R.java file which contains ids of all the resources. Once you have installed the Android SDK you can directly execute the aapt commands.

Android Build Process Steps

• AAPT takes all the resources present in res/ directory and AndroidManifest.xml(meta data of android app) and compiles all the resources. It creates a R.java class which has all the resource ids.

Then all the java files including R.java gets compiled into byte code.

Android application runs on dalvik vm so the byte code is cross compiled to the Dalvik byte code (.dex file)

The .dex file and the compiled resources together forms the .apk file.

Generated apk file is a debug build, to make a release build we need to sign the apk file using a key. You can do this from Android Studio.

• Once you sign the apk file it will be ready to use in production.

Источник

Как устроен билд APK файла внутри

Процесс создания APK и компиляции кода

Рассматриваемые темы

• Архитектура процессоров и необходимость для виртуальной машины
• Понимание Java виртуальной машины
• Компиляция исходного кода
• Виртуальная машина Андроид
• Процесс компиляции в .dex файл
• ART против Dalvik
• Описание каждой части билд процесса
• Исходный код
• Файлы ресурсов
• AIDL файлы
• Модули библиотек
• AAR библиотеки
• JAR библиотеки
• Android Asset Packaging Tool
• resources.arsc
• D8 и R8
• Dex и Multidex
• Подписывание APK файла
• Ссылки

Понимание флоу процесса билда APK файла, среда исполнения и компиляция кода
Этот пост нацелен быть отправной точкой для разработчиков, чтобы они ближе познакомились с билд процессом и созданием APK файла.

Архитектура процессоров и зачем нужна виртуальная машина

Андроид после того как вышел в 2007 году претерпел множество изменений связанный с билд процессом, средой исполнения и улучшениями производительности.

У андроида много удивительных характеристик и одна из них разные архитектуры процессоров такие как ARM64 и x86

Невозможно скомпилировать код, который поддерживает каждую архитектуру. Вот именно поэтому используется Java виртуальная машина.

Понимание Java виртуальной машины

JVM это виртуальная машина, позволяющая устройству запускать код, который скомпилирован в Java байткод

Используя JVM, вы избавляетесь от проблемы с разной архитектурой процессоров.

JVM предоставляет переносимость и она позволяет запускать Java код в виртуальной среде, вместо того, чтобы запускать его сразу «на железе»

Но JVM была создана для систем с большими мощностями по ресурсам, а наш андроид имеет сравнительно мало памяти и заряда батареи.

По этой причине Google создал адаптированную под андроид виртуальную машину, которая называется Dalvik.

Компилируем исходный код

Наш исходный Java код для андроида компилируется в класс файл .class с байткодом с помощью javac компилятора и запускается на JVM

Для котлина есть kotlinc компилятор, который делает совместимый с Java байткод.

Байткод — это набор инструкций, который выполняется на целевом устройстве.

Java байткод — это набор инструкций для Java виртуальной машины.

Андроид виртуальная машина

Каждое андроид приложение работает на своей виртуальной машине. С версий 1.0 до 4.4, это был Dalvik. В андроид 4.4, вместе с Dalvik, Google представил в качестве эксперимента новый андроид runtime, который назывался ART

Сгенерированный класс файл .class содержит JVM Java байткод.

Но у андроида есть свой собственный оптимизированный формат байткода, который называется Dalvik bytecode — это просто инструкции машинного кода для процессора также как и JVM байткод.

Комплияция в .dex файл

Во время компиляции происходит конвертация .class класс файл и .jar библиотеки в один classes.dex файл, который содержит Dalvik байткод.

Команда dx превращает все .class и .jar файлы в один classes.dex файл, который написан с форматом Dalvik байткода.

Dex — это аббревиатура с английского — Dalvik Executable.

ART против Dalvik

C версии 4.4 андроид мигрировал на ART. ART также работает с .dex файлом.

Преимущество ART над Dalvik проявляется в том, что приложения запускаются быстрее, потому что весь DEX байткод транслируется в машинный код во время установки, не нужно дополнительного времени на компиляцию в рантайме.

ART и Dalvik совместимы, так что приложения разработанные для Dalvik должны работать и на ART.

Компиляция Dalvik (JIT- just in time) имела такие минусы как — быстрая трата батареи, лаги в приложениях и плохой перформанс. В Dalvik трансляция происходит только когда это нужно. Мы открываем новый экран и только в этот момент происходит трансляция, за счет этого установка происходит быстрее, но при этом проседает перформанс.

Это причина по которой Google сделал Android Runtime (ART).

ART — основан на AOT (ahead of time) компиляции, она происходит до того как приложение запустится.

В ART компиляция происходит во время установки приложения. Это ведет к более долгому времени установки, но уменьшает трату батареи и избавляет от лагов, которые были на Dalvik.

Несмотря на то, что Dalvik был заменен на ART, .dex формат файлов еще используется

В андроид 7.0 JIT вернулся. Гибридная среда сочетает фичи как от JIT компиляции так и
от ART

Среда запуска байткода это очень важная часть андроида и она вовлечена в процесс запуска и установки приложения

Каждый этап описанного процесса

Source Code (Исходный код)

Это Java и Kotlin файлы в src пакете.

Resource Files

Файлы находящиеся в директории с ресурсами

AIDL Files

AIDL — аббревиатура Android Interface Definition Language, позволяет вам описать интерфейс межпроцессорного взаимодействия.

AIDL — может использоваться между любыми процессами в андроиде.

Library Modules

Модули библиотек содержат Java или Kotlin классы, компоненты андроида и ресурсы.

Код и ресурсы бибилотеки компилируются и пакуются вместе с приложением.

Поэтому модуль библиотеки может считаться компайл тайм артефактом.

AAR Libraries

Андроид библиотеки компилируются в AAR — android archive файл, который вы можете использовать как зависимость для вашего android app модуля.

AAR файлы могут содержать андроид ресурсы и файл манифеста, что позволяет вам упаковать туда общие ресурсы такие как layouts и drawables в дополнение к Java или Kotlin классам и методам.

JAR Libraries

JAR это Java библиотека и в отличие от AAR она не может содержать андроид ресурсы и манифесты.

Android Asset Packaging Tool

AAPT2 — аббревиатура (Android Asset Packaging Tool) — компилирует манифест и файлы ресурсов в один APK.

Этот процесс разделен на два шага компиляцию и линковку Это улучшает производительность так как если вы поменяете один файл, вам нужно компилировать только его и прилинковать к остальным файлам командой ‘link’

AAPT2 может компилировать все типы андроид ресурсов, таких как drawables и XML файлы.

При вызове AAPT2 для компиляции, туда передается по одному ресурсному файлу на каждый вызов

Затем APPT2 парсит файл и генерирует промежуточный бинарный файл с расширением .flat

Фаза линковки склеивает все промежуточные файлы сгенерированные в фазе компиляции и дает нам на выход один .apk файл. Вы также можете сгенерировать R.java файл и правила для proguard в это же время.

resources.arsc

Полученный на выходе .apk файл не включает в себя DEX файл, APK не подписан и не может быть запущен на устройстве.

APK содержит AndroidManifest, бинарные XML файлы и resources.arsc

resource.arsc содержит всю мета информацию о ресурсах, такую как индексы всех ресурсов в пакете

Это бинарный файл и APK который может быть запущен. APK который вы обычно создаете и запускаете не сжат и может быть использован просто посредством размещения в памяти.

R.java файл это выходной файл вместе с APK ему назначен уникальный id, который позволяет Java коду использовать ресурсы во время компиляции.

arsc это индекс ресурса который используется во время запуска приложения

D8 и R8

Начиная с андроид студии 3.1 и далее, D8 был сделан дефолтным компилятором.

D8 производит более маленькие dex файлы с лучшей производительностью, если сравнивать со старым dx.

R8 используется для компиляции кода. R8 это оптимизированная версия D8

D8 играет роль конвертера класс файлов в Dex файлы, а также производит дешугаринг функций из Java 8 в байткод, который может быть запущен на андроиде

R8 оптимизирует dex байткод. Он предоставляет такие фичи как оптимизация, обфускация, удаление ненужных классов.

Обфускация уменьшает размер вашего приложения укорачивая названия классов, методов и полей.

Обфускация имеет и другие преимущества для предотвращения реверс инжиниринга, но основная цель уменьшить размер.

Оптимизация уменьшает размер Dex файла путем переписывания ненужных частей кода и инлайнинга.

С помощью дешугаринга мы можем использовать удобные фичи языка Java 8 на андроиде.

Dex and Multidex

R8 дает на выходе один DEX файл, который называется classes.dex

Если количество методов приложения переваливает за 65,536, включая подключенные библиотеки, то произойдет ошибка при билде

Источник

Build Process

The Xamarin.Android build process is responsible for gluing everything together: generating Resource.designer.cs , supporting the @(AndroidAsset) , @(AndroidResource) , and other build actions, generating Android-callable wrappers, and generating a .apk for execution on Android devices.

Application Packages

In broad terms, there are two types of Android application packages ( .apk files) which the Xamarin.Android build system can generate:

Release builds, which are fully self-contained and don’t require extra packages to execute. These are the packages that are provided to an App store.

Debug builds, which are not.

These package types match the MSBuild Configuration which produces the package.

Shared Runtime

Prior to Xamarin.Android 11.2, the shared runtime was a pair of extra Android packages which provide the Base Class Library ( mscorlib.dll , etc.) and the Android binding library ( Mono.Android.dll , etc.). Debug builds rely upon the shared runtime in lieu of including the Base Class Library and Binding assemblies within the Android application package, allowing the Debug package to be smaller.

The shared runtime could be disabled in Debug builds by setting the $(AndroidUseSharedRuntime) property to False .

Support for the Shared Runtime was removed in Xamarin.Android 11.2.

Fast Deployment

Fast deployment works by further shrinking Android application package size. This is done by excluding the app’s assemblies from the package, and instead deploying the app’s assemblies directly to the application’s internal files directory, usually located in /data/data/com.some.package . The internal files directory is not a globally writable folder, so the run-as tool is used to execute all the commands to copy the files into that directory.

Читайте также:  Pc android emulator indir

This process speeds up the build/deploy/debug cycle because the package is not reinstalled when only assemblies are changed. Only the updated assemblies are resynchronized to the target device.

Fast deployment is known to fail on devices which block run-as , which often includes devices older than Android 5.0. Fast deployment also fails for system applications (android:sharedUserId=»android.uid.system») since run-as is also blocked for system applications.

Fast deployment is enabled by default, and may be disabled in Debug builds by setting the $(EmbedAssembliesIntoApk) property to True .

The Enhanced Fast Deployment mode can be used in conjunction with this feature to speed up deployments even further. This will deploy both assemblies, native libraries, typemaps and dexes to the files directory. But you should only really need to enable this if you are changing native libraries, bindings or Java code.

MSBuild Projects

The Xamarin.Android build process is based on MSBuild, which is also the project file format used by Visual Studio for Mac and Visual Studio. Ordinarily, users will not need to edit the MSBuild files by hand – the IDE creates fully functional projects and updates them with any changes made, and automatically invoke build targets as needed.

Advanced users may wish to do things not supported by the IDE’s GUI, so the build process is customizable by editing the project file directly. This page documents only the Xamarin.Android-specific features and customizations – many more things are possible with the normal MSBuild items, properties and targets.

Binding Projects

The following MSBuild properties are used with Binding projects:

Resource.designer.cs Generation

The Following MSBuild properties are used to control generation of the Resource.designer.cs file:

Signing Properties

Signing properties control how the Application package is signed so that it may be installed onto an Android device. To allow quicker build iteration, the Xamarin.Android tasks do not sign packages during the build process, because signing is quite slow. Instead, they are signed (if necessary) before installation or during export, by the IDE or the Install build target. Invoking the SignAndroidPackage target will produce a package with the -Signed.apk suffix in the output directory.

By default, the signing target generates a new debug-signing key if necessary. If you wish to use a specific key, for example on a build server, the following MSBuild properties are used:

keytool Option Mapping

Consider the following keytool invocation:

To use the keystore generated above, use the property group:

Build Extension Points

The Xamarin.Android build system exposes a few public extension points for users wanting to hook into our build process. To use one of these extension points you will need to add your custom target to the appropriate MSBuild property in a PropertyGroup . For example:

Extension points include:

A word of caution about extending the build process: If not written correctly, build extensions can affect your build performance, especially if they run on every build. It is highly recommended that you read the MSBuild documentation before implementing such extensions.

Target Definitions

The Xamarin.Android-specific parts of the build process are defined in $(MSBuildExtensionsPath)\Xamarin\Android\Xamarin.Android.CSharp.targets , but normal language-specific targets such as Microsoft.CSharp.targets are also required to build the assembly.

The following build properties must be set before importing any language targets:

All of these targets and properties can be included for C# by importing Xamarin.Android.CSharp.targets:

This file can easily be adapted for other languages.

Источник