Android build apk from console

How to make Android apps without IDE from command line

Nov 26, 2017 · 5 min read

A HelloWorld without Android Studio

Update: I’ve made a new course that explain how you can avoid Android Studio and Gradle, but still use IntelliJ iDE:

How to do Android development faster without Gradle

IntelliJ IDE, but not Gradle

In this tutorial, I will show you how you can build/compile an APK (an A n droid app) from your java code using terminal (on Linux) without IDE or in other words without Android Studio. At the end, I will also show you a script to automate the process. In this example, I will use Android API 19 (4.4 Kitkat) to make a simple HelloWorld. I want to say that I will do this tutorial without android command which is deprecated.

1. Install Java

First, you need to install java, in my case, I install the headless version because I don’t use graphics (only command line):

2. Install all SDK tools

Then download the last SDK tools of Android which you can find here:

Download Android Studio and SDK Tools | Android Studio

Download the official Android IDE and developer tools to build apps for Android phones, tablets, wearables, TVs, and…

I recommend to unzip it in the /opt directory inside another directory that we will call “android-sdk”:

Now, we have to install platform tools (which contain ADB), an Android API and build tools.

In fact, if you are on Debian, you can avoid installing platform-tools package and only install ADB like that:

3. Code the application

In this example, I want to compile a simple HelloWorld. So, first, we need to make a project directory:

Then we have to make the files tree:

If you use exernal libraries (.jar files), also make a folder for them:

You have an example here:

How to use JavaMail on Android (without Gradle)

Hello guys!

Make the file src/com/example/helloandroid/MainActivity.java and put that inside:

Make the strings.xml file in the res/values folder. It contains all the text that your application uses:

The activity_main.xml is a layout file which have to be in res/layout:

You also have to add the file AndroidManifest.xml at the root:

4. Build the code

Now, I recommend to store the project path in a variable:

First, we need generate the R.java file which is necessary for our code:

• -m instructs aapt to create directories under the location specified by -J
• -J specifies where the output goes. Saying -J src will create a file like src/com/example/helloandroid/R.java
• -S specifies where is the res directory with the drawables, layouts, etc.
• -I tells aapt where the android.jar is. You can find yours in a location like android-sdk/platforms/android-/android.jar

Now, we have to compile the .java files:

If you have use an external, add it the classpath:

The compiled .class files are in obj folder, but Android can’t read them. We have to translate them in a file called “classes.dex” which will be read by the dalvik Android runtime:

But if you use external libraries, do rather:

If you have the error UNEXPECTED TOP-LEVEL EXCEPTION , it can be because you use old build tools and DX try to translate java 1.7 rather than 1.8. To solve the problem, you have to specify 1.7 java version in the previous javac command:

The -source option specify the java version of your source files. Note that we can use previous versions of Java even we use OpenJDK 8 (or 1.8).

We can now put everything in an APK:

Be aware: until now, we used three AAPT commands, the first and the second one are similar but they don’t do the same. You have to copy the classes.dex file at the root of project like above! Otherwise, AAPT won’t put this file at right place in the APK archive (because an APK is like a .zip file).

The generated package can’t be installed by Android because it’s unaligned and unsigned.

If you want, you can check the content of the package like this:

5. Sign the package

To do so, we firstly create a new keystore with the command keytool given by Java:

Just answer the questions and put a password.

You can sign an APK like this:

Note that apksigner only exist since Build Tools 24.0.3.

6. Align the package

It’s as simple as that:

Alignment increase the performance of the application and may reduce memory use.

7. Test the application

To test the application, connect your smartphone with a USB cable and use ADB:

But before run this command, I recommend to run this one:

If there is an error during installation or running, you see it with that command.

Voila! Here’s the result:

8. Make a script

If you don’t want to run all these steps every time you would like to compile your app, make a script! Here’s mine:

Notes

• You can remove “test” if you just want to compile without testing.
• This script only compile and run the app on the phone. But I can also make a script to automatically generate a new project like this one. I think I have a good idea to do so, but I need to know if you are interested. If it’s the case, please leave a comment or send me an e-mail.
• I can also complete the script for external libraries. Likewise, let me know if you want this.

If you have any questions, don’t hesitate to ask them below or by e-mail ;-)! EDIT: Well I’m very busy actually…

Источник

Пишем и собираем приложения для Android в linux консоли

В данной статье я покажу как можно собрать apk файл в Ubuntu используя лишь
утилиты командной строки.

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

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

Введение

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

Раньше я использовал QPython, но он достаточно тяжел и неудобен в работе. Поэтому я перешел к разработке нативных программ. Даже при поверхностном знании Java
это не составляет больших трудностей.

Данное руководство в большой степени базируется на этом документе: Building an Android App
from the Command Line. Кому интересны подробности, обращайтесь к первоисточнику.

Похожая статья: Пишем, собираем и запускаем HelloWorld для Android в блокноте уже встречалась на этом ресурсе, но в ней было рассмотрена разработка в Windows.

Здесь же я рассмотрю, как можно собрать приложение в linux.

Железо

Тестирование проводилось на стареньком нетбуке с процессором Атом, 1Гб ОЗУ
и 8Гб SSD диска.

Операционная система

Я тестировал приложение на Ubuntu 17.04. Начиная с Ubunu 16.04 android-sdk можно установить через пакетный менеджер.

В принципе, тот же SDK можно
скачать с сайта.
Качать файл из раздела ‘Get just the command line tools’
По сути это не сильно меняет процесс, но через пакетный менеджер все гораздо проще.
Разница будет лишь в путях и установке дополнительных пакетов «android-platform».

Установка пакетов

Итак, приступим к установке.

Будет установлено большое количество пакетов, включая Java.

Далее, в зависимости от требуемой версии Android, необходимо установить нужную
версию пакетов. Для lolipop 5.1 необходимо ставить:

Так же необходимо установить дополнительный пакет.

Если вы планируете устанавливать apk-пакет через adb, то необходимо немного дополнительных настроек.

Настройка adb

С помощью lsusb найти подключенное устройство

И создать файл с правилом:

В файл добавить одну строку:

Здесь «1782» взято из вывода lsusb.

После подключения через adb, на устройстве необходимо подтвердить соединение.

Теперь все готово к работе.

Постановка задачи

Приложение, которое будем собирать немного сложнее, чем ‘Hello world’.

• Требуется по нажатию кнопки взять строку из буфера обмена.
• Вырезать подстроку
• Записать подстроку обратно в буфер.
• С помощь Toast вывести подстроку или сообщение об ошибке.

В общем-то все просто.

Я подготовил пример который возьмем за основу.

Создание подписи

Сначала создадим ключ для подписи файла:

Это нам пригодится позже.

Манифест

Здесь указываем имя приложения в атрибуте «android:label». Так же приложение будет использоваться свою иконку, она указана в атрибуте «android:icon». Сама иконка лежит в каталоге «res/drawable-mdpi» файл «icon.png». В качестве иконки можно взять любой небольшой png файл.

Layout

Файл с расположением элементов находится в каталоге «/res/layout/».

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

Исходный код приложения

Исходный код приложения находится здесь «java/ru/kx13/extractvidid»

Код весьма прост и примитивен, но этот шаблон можно использовать в других приложениях.

Скрипт для сборки

Я не стал использовать утилит сборки типа make или ant, т.к. весь код находится в одном файле и особых преимуществ это не даст. Поэтому это обычный shell скрипт:

Некоторые замечания по поводу путей.

• По умолчанию, переменная BASE указывает на путь, в который пакетный менеджер сохраняет файлы. Если вы ставите SDK вручную, то путь надо будет изменить.
• Если вы используете версию API отличную от 22, то вам надо подправить переменные BUILD_TOOLS и PLATFORM

Сборка и установка

Для сборки просто запустите

Если все настроено правильно никаких сообщений не будет выведено, а в каталоге «build» появится файл «Extractor.apk»

Теперь надо установить наше приложение

Если все прошло нормально, на устройстве появится новое приложение. Можно запускать и пользоваться.

В общем случае можно перекинуть файл apk на устройство любым удобным способом.

Заключение

Как видно из статьи начать разработку в консоли совсем несложно.

Консольные утилиты позволяют разрабатывать программы при весьма небольших ресурсах.

Источник

Сборка Android-приложения. Задачка со звёздочкой

Привет, Хабр! Летом я выступал на Summer Droid Meetup с докладом про сборку Android-приложения. Видеоверсию можно найти здесь: habr.com/ru/company/funcorp/blog/462825. А для тех, кто больше любит читать, я как раз и написал эту статью.

Речь пойдёт о том, что же это такое — Android-приложение. Мы соберём разными способами Hello, world!: начнём с консоли и посмотрим, что вообще происходит под капотом систем сборки, потом вернёмся немного в прошлое, вспомним про Maven и изучим современные решения Bazel и Buck. И, наконец, всё это сравним.

Мы задумались о возможной смене системы сборки, когда начинали новый проект. Нам казалось, что это неплохая возможность поискать какие-нибудь альтернативы Gradle. Тем более, что делать это проще на старте, чем переводить существующий проект. К этому шагу нас подтолкнули следующие недостатки Gradle:

• у него определённо есть проблемы с инкрементальной сборкой, хотя видны подвижки в этом направлении;
• он плохо справляется с очень большими монолитными проектами;
• бывает, что весьма долго стартует демон;
• требователен к машине, на которой выполняется.

Прежде всего вспомним, из чего состоит Android-приложение: скомпилированного кода, ресурсов и AndroidManifest.xml.

Исходники находятся в файле classes.dex (файлов может быть несколько, в зависимости от величины приложения) в специальном dex-формате, с которым умеет работать виртуальная машина Android. Нынче это ART, на более старых девайсах — Dalvik. Помимо этого можно встретить папку lib, где по подпапкам разложены нативные исходники. Они будут носить названия в зависимости от целевой архитектуры процессора, например x86, arm и т.д. Если вы используете exoplayer, то lib у вас наверняка присутствует. И папка aidl, которая содержит в себе интерфейсы межпроцессного взаимодействия. Они пригодятся, если нужно обратиться к сервису, запущенному в другом процессе. Такие интерфейсы используются и в самом Android, и внутри GooglePlayServices.

Различные некомпилируемые ресурсы вроде картинок лежат в папке res. Все компилируемые ресурсы, такие как стили, строки и т.д., сливаются в файл resource.arsc. В папку assets, как правило, складывают всё, что не укладывается в ресурсы, например кастомные шрифты.

Кроме всего этого, в APK содержится AndroidManifest.xml. В нём мы описываем различные компоненты приложения, такие как Activity, Service, разные разрешения и т.д. Он лежит в бинарном виде, и чтобы заглянуть внутрь, его надо будет сперва сконвертировать в человекочитаемый файл.

CONSOLE

Теперь, когда мы знаем, из чего состоит приложение, можем попробовать собрать Hello, world! из консоли, используя инструменты, которые предоставляет Android SDK. Это довольно важный этап для понимания того, как работают системы сборки, потому что все они в той или иной мере опираются на эти утилиты. Так как проект написан на Kotlin, нам потребуется его компилятор для командной строки. Его несложно загрузить отдельно.

Сборку приложения можно поделить на следующие этапы:

• загружаем и распаковываем все библиотеки, от которых зависит проект. В моём случае это библиотека обратной совместимости appcompat, которая, в свою очередь, зависит от appcompat-core, поэтому выкачиваем и её;
• генерируем R.java. Этот чудесный класс содержит в себе идентификаторы всех ресурсов в приложении и используется для того, чтобы обращаться к ним в коде;
• компилируем исходники в байт-код и транслируем его в Dex, потому что виртуальная машина Android с обычным байт-кодом работать не умеет;
• упаковываем всё в APK, но сначала выравниваем все несжимаемые ресурсы, такие как картинки, относительно начала файла. Это позволяет ценой совершенно незначительного роста размера APK существенно ускорить его работу. Таким образом система напрямую может отображать ресурсы в оперативную память, используя функцию mmap().
• подписываем приложение. Эта процедура защищает целостность APK и подтверждает авторство. И благодаря этому, например, Play Market может проверить, что приложение было собрано именно вами.

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

MAVEN

Он был разработан ребятами из Apache Software Foundation для сборки Java-проектов. Билд-конфиги для него описываются на языке XML. Ранние ревизии Maven собирались Ant, а сейчас они перешли на последний стабильный релиз.

• он поддерживает кеширование артефактов сборки, т.е. инкрементальный билд должен быть быстрее чистого;
• умеет разрешать сторонние зависимости. Т.е. Когда вы в конфиге Maven или Gradle указываете зависимость от сторонней библиотеки, вам не нужно заботиться о том, от чего она зависит;
• есть куча подробной документации, потому что он уже весьма давно на рынке.
• и он может быть привычным механизмом сборки, если вы недавно пришли в мир Android-разработки из бэкенда.

Минусы Maven:

• зависит от версии Java, установленной на машине, на которой происходит сборка;
• Android-плагин сейчас поддерживается сторонними разработчиками: лично я считаю это весьма существенным недостатком, потому что в один прекрасный день они могут перестать это делать;
• XML не очень подходит для описания билд-конфигов в силу своей избыточности и громоздкости;
• ну и как мы позднее увидим, он работает медленнее Gradle, по крайней мере на тестовом проекте.

Для сборки мы должны создать pom.xml, который содержит описание нашего проекта. В заголовке указываем базовые сведения о собираемом артефакте, а так же версию Kotlin.

По цифрам всё выходит не слишком радужно. Чистая сборка занимает порядка 12 секунд, тогда как инкрементальная — 10. Это говорит о том, что Maven как-то плохо переиспользует артефакты предыдущих сборок, либо, что на мой взгляд более вероятно, плагин для сборки Android-проекта мешает ему это делать

Используют сейчас всё это, я думаю, прежде всего создатели плагина — ребята из simpligility. Больше достоверных сведений об этом вопросе найти не удалось.

BAZEL

Bazel изобрели инженеры в недрах Google для сборки своих проектов и относительно недавно перевели его в open source. Для описания билд-конфигов используется питоноподобный Skylark или Starlark, оба названия имеют место быть. Собирается с использованием своего же последнего стабильного релиза.

• поддержка разных языков программирования. Если верить документации, то он умеет собирать проекты для iOs, Android или даже бэкенда;
• умеет кешировать ранее собранные артефакты;
• умеет работать с Maven-зависимостями;
• у Bazel очень крутая, на мой взгляд, поддержка распределённых проектов. Ему можно в качестве зависимостей указывать конкретные ревизии git-репозиториев, и он будет сам их выгружать и кешировать в процессе сборки. Для поддержки масштабируемости Bazel умеет, например, распределять различные таргеты по облачным билдсерверам, что позволяет очень быстро собирать громоздкие проекты.

Минусы Bazel:

• всю эту прелесть весьма тяжело поддерживать, потому что билд-конфиги очень подробные и описывают сборку на низком уровне;
• помимо прочего, кажется, что Bazel сейчас активно развивается. Из-за этого некоторые примеры не собираются, а те, что собираются, могут использовать уже устаревший функционал, который помечен как deprecated;
• документация сейчас также оставляет желать лучшего, особенно в сравнении с Gradle;
• на маленьких проектах прогрев и анализ билд-конфигов может занимать больше времени, чем сама сборка, что не есть хорошо, на мой взгляд.

Концептуально базовый конфиг Bazel состоит из WORKSPACE, где мы описываем всякие глобальные вещи для проекта, и BUILD, который содержит непосредственно таргеты для сборки.
Опишем WORKSPACE. Так как у нас Android-проект, то первое, что мы конфигурируем, — это Android SDK. Также тут импортируется правило для выгрузки конфигов. Потом, так как проект написан на Kotlin, мы должны указать правила для него. Тут мы делаем это, ссылаясь на конкретную ревизию прямо из git-репозитория.

Теперь приступим к BUILD.

Сперва импортируем правило для сборки Kotlin и описываем то, что хотим собрать. В нашем случае это Android-приложение, поэтому используем android_binary, где задаём манифест, минимальный SDK и т.д. Наше приложение будет зависеть от исходников, поэтому упоминаем их в deps и переходим к тому, что они собой представляют и где их найти. Код также будет зависеть от ресурсов и библиотеки appcompat. Для ресурсов используем обычный таргет для сборки андроидных исходников, но задаём ему только ресурсы без java-классов. И описываем пару правил, которые импортируют сторонние библиотеки. Тут также упоминается appcompat_core, от которой зависит appcompat.

По цифрам для такого маленького проекта всё выглядит печально. Больше половины минуты на чистую сборку Hello, world! — очень много. Время инкрементальной сборки также далеко от совершенства.

Bazel используют его создатели (Google) для каких-то своих проектов, в том числе серверных, а также Dropbox и Huawei, которые собирают им мобильные приложения. И небезызвестный Dagger 2 также собирается Bazel.

Его придумали перебежчики из Google в Facebook. Для описания конфигов раньше он использовал Python, а потом мигрировал на упоминавшийся сегодня Skylark. Собирается же он, внезапно, с помощью системы Ant.

• поддерживает разные языки программирования и умеет собирать как Andriod, так и iOS;
• умеет кешировать ранее собранные артефакты;
• для Buck сделали свою реализацию dex, которая работает пошустрее стандартной и висит вместе с демоном системы. Так они экономят время на инициализации dex. Инженеры действительно многое оптимизировали. Например, Buck не собирает код, который зависит от библиотеки, если при изменении внутренностей библиотеки не изменился интерфейс. Аналогично и для ресурсов: если идентификаторы не поменялись, то при изменении ресурсов код не пересобирается.
• есть плагин, который умеет прятать Buck за гредловским конфигом. Т.е. вы получаете примерно обычный Gradle-проект, который на самом деле собирается через Buck.

Минусы Buck:

• его так же сложно поддерживать, как Bazel. Т.е. тут так же надо описывать низкоуровневые правила, четко описывающие процесс сборки;
• кроме прочего, Buck не умеет сам разрешать Maven-зависимости.

Итак, как выглядит конфиг сборки Hello, world! посредством Buck? Тут мы описываем один файл конфигурации, где указываем, что хотим собирать Android-проект, который будет подписан дебажным ключом. Приложение аналогичным образом будет зависеть от исходников — lib в массиве deps. Дальше идёт таргет с настройками подписи. Я использую дебажный ключ, который идёт в комплекте с Android SDK. Сразу за ним следует таргет, который соберёт нам исходники Kotlin. Аналогично Bazel, он зависит от ресурсов и библиотек совместимости.

Описываем их. Для ресурсов в Buck есть отдельный таргет, поэтому велосипеды не пригодятся. Следом идут правила для скачанных сторонних библиотек.

Собирается всё это дело очень резво. Чистая сборка занимает немногим более 7 секунд, тогда как инкрементальная — совершенно незаметные 200 миллисекунд. Я думаю, это очень хороший результат.

Так делают в Facebook. Кроме своего флагманского приложения, они собирают им Facebook Messenger. И Uber, которые сделали плагин для Gradle и Airbnb с Lyft.

Выводы

Теперь, когда мы поговорили про каждую систему сборки, можно сравнить их между собой на примере Hello, world! Консольная сборка радует своей стабильностью. Время выполнения скрипта из терминала можно считать эталонным для сборки чистых билдов, потому что сторонние затраты на парсинг скриптов тут минимальны. Явным аутсайдером я бы в данном случае назвал Maven за чрезвычайно незначительное убыстрение инкрементальной сборки. Bazel очень долго парсит конфиги и инициализируется: есть мысль, что он кеширует как-то результаты инициализации, потому что инкрементальная сборка у него проходит существенно быстрее чистой. Buck — бесспорный лидер это подборки. Очень быстрая как чистая, так и инкрементальные сборка.

Сравним теперь все за и против. Не буду включать Maven в сравнение, потому что он явно проигрывает Gradle и уже практически не используется на рынке. Buck и Bazel я объединю, потому что они обладают примерно одинаковыми достоинствами и недостатками.

Итак, про Gradle:

• первое и, на мой взгляд, самое важное — он простой. Очень простой;
• из коробки разруливает и выгружает зависимости;
• для него очень много самых разных обучалок и документации;
• активно поддерживается как Google, так и сообществом. Здорово интегрирован с Android Studio, текущим флагманским инструментом разработки. И все новые фичи для сборки Android-приложения сперва появляются именно в Gradle.

Про Buck/Bazel:

• определённо могут быть очень быстрыми в сравнении с Gradle. Полагаю, что это особенно заметно на очень больших проектах
• можно держать один проект, в котором будут исходники и iOS, и Android, и собирать их одной системой сборки. Это позволяет шарить между платформами некоторые части приложения. Например, так собирается Chromium;
• заставляют подробно описывать зависимости и таким образом буквально принуждают разработчика к многомодульности.

Не забудем и про минусы.

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

iFUNNY

Возможно, у вас возник вопрос, как мы собираем iFunny. Так же, как и многие — используя Gradle. И на то есть причины:

1. Пока непонятно, какой выигрыш в скорости сборки нам это даст. Чистая сборка iFunny занимает почти 3 минуты, а инкрементальная — около минуты, что на самом деле не особо долго.
2. Билд-конфиги Buck или Bazel сложнее поддерживать. В случае Buck нужно ещё и следить за актуальностью подключенных библиотек и библиотек, от которых они зависят.
3. Это банально дорого — переводить существующий проект с Gradle на Buck/Bazel, особенно в условиях непонятного профита.

Если у вас проект собирается больше 45 минут и в команде Android-разработки человек 20, то есть смысл задуматься о смене системы сборки. Если вы со своим другом пилите стартап, то пользуйтесь Gradle и отбросьте эти мысли.

Буду рад обсудить перспективы альтернатив Gradle в комментариях!
Ссылка на проект

Источник