Compiling android on windows

How to Build Android Kernel on Windows 10

Appual’s has a few great guides on Android development, such as How to Build a Custom ROM from Android Open Source Project – but these guides are usually geared towards a pure Linux build environment.

In this guide, we are going to show you how to build an Android kernel on Windows 10 – yes, we will still be using a Linux build environment, but it will be a Linux subsystem within Windows 10. So if you are a Windows 10 user interested in developing for Android, follow our guide carefully.

In this guide, we will specifically be learning how to build a kernel for ARM and MediaTek devices, adding features, and a basic overview of using Git.

Requirements

• Windows 10 x64 (with Fall Creator’s update)

Setting up the Linux Environment

1. On Windows 10, go to Settings > Update and Security > For Developers > enable Developers Mode.
2. Now go to Control Panel > Programs > Turn Windows Features On or Off > enable Windows Subsystem for Linux.
3. Reboot your PC.
4. Launch the Linux subsystem, and allow it to go through the download process. Set a password and don’t lose it.
5. Now go to the Windows app store, and download Ubuntu.
6. Launch Ubuntu on the Windows 10 desktop, and it will request a username and password.
7. In Ubuntu, launch the native terminal and type the following command: apt-get update
8. This will proceed to update all repos for apps and dependencies.
9. Next in the terminal type: sudo apt-get install -y build-essential kernel-package libncurses5-dev bzip2
10. In order to check if all dependencies were correctly installed, type ‘gcc’ in the terminal (no quotes).
11. If “gcc” is already installed, you should see “gcc : fatal error : no input file”
12. Now you can type ‘make’ in the terminal. If “make” is already installed, you should see “make: *** no target specified and no makefile found. stop.”
13. Next type ‘git’, and iff “git” is already installed, you should see bunch of basic git commands.
14. Now we need some toolchains (there are several types, including GCC, Linaro, and a handful of custom ones). Some devices may require different toolchains, for example, not all device kernels will boot or compile with GCC.

For ARM Devices

We will be using GCC 4.7 for this.

1. Open the Linux terminal and type: mkdir kernel
2. Now type: cd kernel
3. (it doesn’t have to be ‘kernel’, this is for simplicity sake, you can name it whatever you want.)
4. Now type: git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7

For ARM 64 Devices

You need a 64-bit kernel compiler for ARM 64 devices, for example aarch64.

Getting the Source Files for your Device

This is a tricky part, as you need to find a GitHub repo that hosts your kernel source. You will of course need to search for it, most likely it can be found on XDA forums.

On the upper left side, you should see “Branch: Completed by xxxx”.

There are different versions of a kernel / project, usually separated by “Testing”, “Beta”, “Final Release”, etc.

The kernel folders are typically as follows:

• /arch/arm/configs: This contains various config files for the device, such as governors, etc.
• /output/arch/arm/boot/: This is where the zimage will be stored.
• build.sh: A script that will simplify the building process.
• /arm-cortex-linux-gnueabi-linaro_5.2-2015.11-2: This is typically a toolchain placed in the kernel source, thus making it easier to find.

You are going to need to download your kernel source.

Open the Linux terminal and make sure that you are in the kernel folder you previously created (cd kernel).

Then type in terminal: “git clone “URL of the github kernel” -b “name of the branch”

Building the Kernel

To make it easier, you can navigate to the location in the file explorer. It should be /home/user ID/kernel (or whatever you named the kernel folder).

You should see two folders inside, for the toolchain and the kernel source. Go inside the kernel source folder.

For ARM Devices

In a terminal, type the following commands:

Here is an overview of what these commands do, to make this easier in the future.

• #!/bin/bash: Tells the script to run in shell command
• export ARCH=arm: Defining which kernel architecture type it is (For example arm64 etc)
• export CROSS_COMPILE= : Locate where the toolchain is. It must match the exact path, and the dash in the end is really mandatory.
• mkdir output: This creates a directory for saving the compiled zimage
• make -C $(pwd) O=output : Defining defconfig for guiding kernel compilation.
• make -j4 -C $(pwd) O=output: When the building process begins, -j# tells it how fast to try and compile. Typically, you set this number according to your CPU. Setting on -j32 on a budget CPU, for example, would probably cause massive instability.
• cp output/arch/arm/boot/Image $(pwd)/arch/arm/boot/zImage: This is for moving image to a second path.

For ARM 64 Devices

For Mediatek (MTK) Devices

When you have completed the steps necessary to your kernel architecture, you can type in the terminal: sudo bash build.sh

You will then enter your user password, and the compiling process will begin.

It may take a while but typically not very long, compiling a kernel is not like compiling an entire Android ROM. This is really CPU dependent – for example, an AMD Phenom X4 3.4GHz with 8GB of RAM should take around 10 minutes to compile from start to finish.

When it finishes, it should notify you with a message like “zimage is ready”.

ARM and ARM64 Devices

Go to “/Output/arch/arm/boot/” to find your zimage.

Mediatek Devices

Go to “/arch/arm/boot/” to find your zimage.

Not all kernel builds will result in a Zimage file, it can sometimes be built as other image formats.

Important: If you are going to compile again, it is recommended that you enter the commands make clean and make mrproper before you begin the compile process again.

Making the Kernel Boot

There are two options for you to choose.

You can either use the anykernel method (as defined by XDA user @osm0sis in this XDA thread). You should read the entire tutorial, but a summary of the steps is as follows:

1. Place zImage in the root (dtb and/or dtbo should also go here for devices that require custom ones, each will fallback to the original if not included)
2. Place any required ramdisk files in /ramdisk and modules in /modules (with the full path like /modules/system/lib/modules)
3. Place any required patch files (generally partial files which go with commands) in /patch
4. Modify the anykernel.sh to add your kernel’s name, boot partition location, permissions for included ramdisk files, and use methods for any required ramdisk modifications (optionally, also place banner and/or version files in the root to have these displayed during flash)
5. `zip -r9 UPDATE-AnyKernel2.zip * -x .git README.md *placeholder`

The other method you have available is unpacking the boot.img from the same ROM (such as CM, TouchWiz, EMUI, etc.) and the same Android version. You would then swap the Zimage. Again, this is a really complicated process and you should read the exact tutorial, but a summary of the steps is:

1. Unzip.
2. Either use the command-line “unpackimg ”, or simply drag-and-drop the image. This will split the image and unpack the ramdisk to a subdirectory.
3. Alter the ramdisk as you like.
4. The repackimg batch script requires no input and simply recombines the previously split zImage with the newly packed modified ramdisk using all the original image information (which was also split and saved).
5. The cleanup batch script resets the folder to its initial state, removing the split_img+ramdisk directories and any new packed ramdisk or image files.

Before you flash your kernel, you should create a backup of your stock boot.img, and then flash your kernel to see if it allows your Android system to boot.

Adding Features to Your Kernel

Adding features to your kernel is a great way to spice it up. There are a lot of things you can tweak, such as CPU governors, IO schedulers, overclocking the GPU, audio enhancements, etc.

An example for adding a governor is here (this governor is codenamed Intellimm).

We can see in the first 2 text boxes that in “arch/arm/configs/” “msm8974_sec_defconfig” and “cm_msm8974_sec_defconfig” have been modified.

Between the lines 140 and 141 of this files this text has been added : “CONFIG_CPU_FREQ_GOV_INTELLIMM=y”
(This line is for enabling Intellimm when you’re compiling your kernel)

Same technique applies to the other text boxes (what has been added and deleted and it’s location)

Depending on the features you add, more or less files can be modified, added or deleted.

So to sum it up, a Commit let’s you see all the changes which have been made and everything else!

General Tips and Tricks

How to change the kernel name and version:

The simple method:

Edit this line in your defconfig file:

The advanced methods:

Navigate to the Makefile in the root folder of your kernel source.

Add these lines:

DO NOT modify the lines Version, PatchLevel, Sublevel, or Extraversion.

Alternative method:

Go to scripts/mkcompile_h and add these lines:

Solving PATH problems:

If you encounter the error “Is your path correct?”, try this in the Linux terminal:

Accessing your Ubuntu folders from Windows 10

Your path to Ubuntu should typically be:

But you should not edit files directly from Windows, as this will typically break the permissions on them – you would then need to reset the permissions from within Linux terminal.

Источник

Компиляция и сборка Android приложения (как это работает)

Дисклеймер: Я не 23 летний сеньор (мне 19 и до сеньора мне еще ой как далеко, года 4, поэтому супер статьи от меня не ждите.

Основа пути моего, разработчика как — обучение/изучение нового постоянное. Надеюсь, у вас тоже.

Я бы хотел подробно рассмотреть процесс компиляции и сборки Android приложения в конечный .apk. Да, при разработке очередного приложения какашкибезholoстилей эта информация вам нафиг не сдалась, но для общего развития будет полезна всем Android разработчикам.

Конечно, можно было бы ограничиться инструкцией вроде:

• Напишите код
• Нажмите кнопочку Build & Run в вашей IDE
• Продолжайте быть Android разработчиком

Но мы не ищем легких путей.

Примечание:
Это не перевод http://developer.android.com/tools/building/index.html, это статья, основанная в том числе и на данной документации.

В общих чертах процесс сборки приложения выглядит так:

Нас особенно интересует второй этап (компиляция и сборка ресурсов), так что, рассмотрим его более подробно (21 этап как никак):

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

(Оригинал здесь: developer.android.com/tools/building/index.html)

Что есть что на диаграмме:

1. Ресурсы приложения — это все xml ресурсы из папки res вашего проекта + некомпилируемые бинарные ресурсы, например, картинки из res/drawable или файлы из /res/raw, а так же файлы из /assets/

2. aapt — утилита, которая ищет в вашем проекте компилируемые ресурсы, такие как AndroidManifest.xml и xml файлы из res/ и компилирует их в бинарное представление, а изначально бинарные ресурсы, такие как картинки, и файлы из /res/raw и /assets не компилируются. Далее, эта утилита генерирует важнейший класс R.java для вашего приложения, благодаря которому вы можете обращаться к ресурсам из вашего кода без всяких заморочек с чтением файлов, как скажем с /assets.

Кстати, кроме компиляции xml ресурсов, aapt создает файл resources.arsc, который представляет собой таблицу для маппинга ресурсов во время выполнения приложение, туда входят все ресурсы из /res/, в том числе и /res/raw/, содержимое /assets не включается в таблицу.

Полезно знать: Утилита aapt находится в папке platform-tools вашего Android SDK. Если вам захотелось сделать реверс-инжиниринг скомпилированных ресурсов приложения, вы можете воспользоваться apk-tool (https://code.google.com/p/android-apktool/)

3. R.java — класс, генерируемый утилитой aapt для того, чтобы вы могли обращаться к ресурсам из папки res без явной работы с файловой системой через библиотеки ввода/вывода.

Если кто-то еще не знал — всякие R.string, R.menu и прочее — это статические вложенные классы, а в R.string.app_name, app_name — public static final int поле класса. Получается, что правило-принцип CamelCase, применяемый в Java, для них нарушен, должно то быть: R.String, R.Menu, а с константами — R.String.APP_NAME, айайай Google.

4. Исходный код приложения — это ваши (или украденные форкнутые с других проектов) .java файлы с кодом проекта из папки src, все просто.

5. Java интерфейсы — это не те, обычные интерфейсы (обычные входят в состав исходного кода приложения, предыдущий пункт), которые вы используете в вашем коде, это интерфейсы, сгенерированные утилитой aidl (следующий пункт содержит пояснение).

6. .aidl файлы — это интерфейсы, которые вы можете написать на Java с немного необычным синтаксисом (на самом деле, язык называется AIDL — Android Interface Defenition Language). Такие интерфейсы нужны для описания взаимодействия между различными процессами, например когда вам нужно, чтобы сервис (Service) вашего приложения работал не просто в отдельном потоке, а именно в отдельном процессе (у такого подхода есть как преимущества, например, раздельные квоты на память для процессов, так и недостатки — необходимость использования aidl), на Хабре есть статья, в которой раскрыта тема использования aidl http://habrahabr.ru/post/139432/).

7. aidl — утилита, которая транслирует ваши .aidl файлы в Java код, она находится в папке platform-tools вашего Android SDK.

8. Java компилятор — (наконец-то мы до него добрались!) это обычный javac из вашего JDK, которому дают на обработку исходный код приложения (4), R.java (3) и интерфейсы aidl, которые переведены в java код с помощью утилиты aidl

9. .class файлы — это «выхлоп» javac — байткод для JVM. Так как Dalvik VM не может интерпретировать java bytecode, а использует свой велосипед под название dex bytecode, то на этом компиляция проекта не заканчивается.

Разработчики Android выбрали регистровую архитектуру Dalvik VM, вместо привычной для JVM — стековой архитектуры из двух ключевых соображений:
1. Производительность регистровой ВМ выше (инфа 100%), особенно на процессорах с RISC-архитектурой, а это все ARM процессоры. Первые версии Dalviik VM даже не включали JIT (до Android 2.2), но давали терпимую производительность приложений, скажем я не испытывал особых проблем с HTC Desire на 2.1.
2. java bytecode транслируется в меньший по объему dex bytecode, что уменьшает размер скомпилированного приложения.

10. dex компилятор (а точнее транслятор) — он транслирует .class файлы в classes.dex (Java bytecode в Dalvik bytecode). Описание .dex вы можете прочитать здесь source.android.com/tech/dalvik/dex-format.html.

Сам компилятор находится в папке platform-tools вашего Android SDK, запускать его можно через dx.bat (для Windows), при этом будет задействован dx.jar из папки platform-tools/lib

11. Сторонние библиотеки и .class файлы — это все то, что вы подключаете в проект как библиотеку или включаете в Build Path. Так как в качестве основного ЯП для Android выбрана Java, вы можете без проблем использовать практически любые java библиотеки, они просто будут обработаны dex компилятором.

12. classes.dex — в данный файл dex компилятор записывает весь исполняемый код вашего проекта.

Да-да, все будет в одном файле, хотя в документации написано, что файлов .dex может быть несколько, но на практике, я не встречал, чтобы .apk содержал .dex файлы кроме classes.dex, может в комментариях меня поправят.

13. Скомпилированные ресурсы — xml ресурсы приложения, скомпилированные в бинарное представление.

14. Другие ресурсы — это реально другие ресурсы, которые не обрабатываются aapt — например файлы, которые вы зачем то хотите засунуть в .apk, так же туда попадают файлы из .jar`ов, которые добавлены в Build Path, но не являются компилируемыми.

15. apkbuilder — утилита, которой на вход подают скомпилированные ресурсы (2, 13), classes.dex (12) и другие ресурсы (14), а она собирает из этого наш вожделенный .apk файл. Утилита лежит в папке tools вашего Android SDK

16. Собранное приложение в файл .apk — это архив, содержащий скомпилированные и нескомпилированные ресурсы, classes.dex, resources.arsc, META-INF, AndroidManifest.xml и т.д.
Формат .apk это надстройка над .jar, а .jar — надстройка над zip, так что, .apk вы можете открыть zip архиватором, такая вот матрешка.

17. jarsigner — это Oracle`вская утилита для подписания .jar архивов. Он подписывает ваш .apk выбранным вами ключом.

Но не надо думать, что ваш .apk теперь защищен от декомпиляции, ничего подобного. В .apk только добавляется папка META-INF, в которой вы можете обнаружить публичную часть release (или debug) сертификата — файл CERT.RSA, а так же файл CERT.SF — который содержит контрольные суммы для всех файлов внутри .apk, кроме тех, что в папке META-INF

Пример содержания CERT.SF:
Signature-Version: 1.0
SHA1-Digest-Manifest-Main-Attributes: O1qITQssq6nv0FUt+eR1aLnqk5w=
Created-By: 1.6.0_43 (Apple Inc.)
SHA1-Digest-Manifest: OwzyFA/Qjd+5X1ZwaJQSxFgdciU=

Name: res/drawable-mdpi-v4/ic_premium_pin.png
SHA1-Digest: 8ksQB8osCHTnMlpL6Ho/GDc719Q=

Name: res/drawable/round_bottom_white.xml
SHA1-Digest: rQelve4dQmwCfkVlYZ2+9j5aW5w=

Еще немного важной информации о подписи приложения:
В Android уникальным идентификатором приложения является имя пакета приложения, например ru.habrahabr.android. Но чтобы злоумышленник не смог подменить ваше установленное приложение на свое с таким же пакетом, Android выполняет проверку, на то чтобы новый .apk был подписан тем же сертификатом, что и уже установленный.

Кроме того, если у вас есть выложенное приложение в Google Play, вы не сможете обновить его, если новая версия подписана другим сертификатом! Так что советую забекапить сертификат, а так же не забыть пароль к нему. Иначе вы не сможете обновлять свои приложения.

18. Debug или Release хранилище ключей — хранилище из которого jarsigner возьмет ключи для подписи приложения. Если вы собираете Debug версию (для запуска на эмуляторе или подключенном устройстве), то .apk подписывается debug ключем, в Windows он находится в папке пользователя/.android/.

Кстати, приложение подписанное debug ключом нельзя установить без подключенного отладчика. Так что, если хотите отправить .apk друзьям на тестирование — подпишите его Release ключем

19. Подписанный .apk — .apk файл вашего приложения, в который добавлена информация о подписи (см. пункт 17).

20. zipalign — утилита, которая оптимизирует ваш .apk для более быстрого запуска и меньшего потребления ОЗУ при работе приложения. Она выравнивает содержимое .apk для более эффективной разархивации (подробнее здесь: http://developer.android.com/tools/help/zipalign.html).

Важное замечание: приложение надо сначала подписать, а затем применить zipalign, т.к. подпись — это добавление папки META-INF в архив, а это изменение архива, следовательно нарушение его оптимизации. То есть, если вы сначала примените zipalign, а потом измените архив — смысла в zipalign не будет. Насчет нарушения контрольных сумм, которые рассчитала утилита jarsign, бояться не стоит, т.к. zipalign делает оптимизации по выравниванию данных в архиве, все это происходит на уровне zip, сами данные не изменяются.

Хозяйке на заметку: во время сборки debug версии проекта zipalign не вызывается, скорее всего, чтобы вы не ждали выполнения еще и этой операции (спасибо и на этом).

21. Подписанный (и, возможно, выравненный) .apk — вожделенный .apk вашего приложения. Конец.

Я думаю, что теперь понятно, почему сборка и запуск Android приложения происходит так долго 🙂 Так что, советую поставить SSD, ну и процессор побыстрее и сэкономить себе нервы и время.

Немного полезного оффтопа:

1. Всегда используйте обфускацию вашего кода. Декомпилировать java приложение очень легко. Даже несмотря на то, что в .apk используется dex bytecode — его сначала транслируют обратно в java bytecode, а затем к нему применят обычные java декомпиляторы. Потратьте пару часов на выбор и настройку обфускатора, иначе можете просто выложить исходники проекта на гитхаб, секономите людям время, а может еще и пулл реквесты получите 🙂

2. Вы знали, что Android инстанциирует для каждого запущенного приложения отдельный экземпляр Dalvik VM? Это сделано для того, чтобы исключить ситуации, когда одно приложение валит Dalvik VM, а за ним тянет все другие запущенные приложения. Яркий пример подобного вмешательства — Facebook, они через reflection изменяют параметры Dalvik VM (не стоит так делать). Если бы Android использовал один инстанс Dalvik — это изменение затронуло бы все запущенные приложения.

3. Dalvik VM не является JVM, т.к. во-первых он не понимает java bytecode, а во-вторых не реализует спецификации для JVM, т.к. использует свой байт код. Так что, советую называть Dalvik VM именно Dalvik VM.

Надеюсь, вы не зря потратили свое время и узнали что-то новое.

Источник