Aapt exe android sdk

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, о тестировании, мысли, рекомендации, инструкции.

9 мая 2016 г.

Android SDK. Тестируем по-настоящему!

Android SDK

Мы подбираемся всё ближе и ближе к инструментам и методам тестирования. Инструменты для тестирования, а также всякий вспомогательный инструментарий, входит в состави Android SDK. Самые нужные компоненты из состава SDK, конкретно для тестировщиков, это инструменты SDK, они же SDK tools, инструменты сборки, они же Build tools (внезапно, да?) и инструменты платформы, они же Platform tools. Нет никакого смысла запоминать это. Я просто сказал названия папок из установленного пакета Android SDK:

Рис. 1. Содержание папки Android SDK

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

SDK Tools

Эмулятор

Вообще называется он «Android Virtual Device» (AVD). Он позволяет создавать виртуальные устройства как из шаблонов, типа Nexus 6, Nexus 4, просто «Устройство с экраном на 7 дюймов», так и совсем кастомные, а также и создавать свои шаблоны. Достоинство и недостаток виртуальных устройств именно в их эмуляции. В отличие от виртуальных машин, где, очень грубо и просто говоря, аппаратные возможности и сами устройства хостовой ОС пробрасываются в гостевую ОС, эмулятор вынужден предоставлять совершенно другую архитектуру — ARM. И от того эмулятор ужасно тормозит. За этого его не любят.
Впрочем на Intel процессорах хостовой ОС можно установить HAXM (Intel Hardware Accelerated Execution), который также можно найти в SDK (в extras), и получить отличный прирост производительсности эмулятора Intel процессора. Однако это доступно только для владельцев Intel и на процессорах от AMD HAXM не работает. Но в любом случае, x86 эмуляторы побыстрее ARM’овских.

Вторая, но гораздо более важная проблема, заключается в том, что периодически эмулятор просто отваливается. Вы можете взаимодействовать с ним мышкой и горячими клавишами, но не можете подцепиться через adb (про который я расскажу дальше). Без доступа по adb эмулятор становится просто не нужен. Здесь, кстати, может спасти альтернативный эмулятор — Genymotion, который сделан для исправления типичных проблем штатного эмулятора (и очень популярен!).

Почему же эмулятор ещё жив, если есть реальные устройства, есть альтернативы? Благодаря эмулятору вы можете, например, посмотреть, как будет выглядеть интерфейс приложения на устройстве, которого у вас нет: вы можете в несколько кликов создать вируальное устройство, задав нужное разрешение, плотность точек, соотношение сторон, и поглядеть на интерфейс. Можно и быстро посмотреть реакцию на типовые ситуации — изменение громкости, поворот экрана, изменение скорости подключения к сети и подобное. К тому же образы Android (кстати, образы Android для эмулятора — практически оригинальный AOSP!) обновляются очень оперативно. У вас может не быть образа для Nexus устройства, но для эмулятора он всегда есть. Эмулятор всегда под рукой.

Monitor

Или, как его звали в молодости, DDMS. DDMS теперь (на самом деле давно) деприкейтед, то есть объявлен устаревшим, и эту аббревиатуру можно не запоминать. Расшифровывается она, кстати, Dalvik Debug Monitor Service. Dalvik — это и есть та виртуальная машина, в которой работают Android приложения. Dalvik жил до Android 4.4 включительно, а в Android 5.0 он был заменён на виртуальную машину ART — Android Runtime.
Одно из ключевых отличий ART от Dalvik, в глазах пользователя, это то, что Dalvik компилировал приложения при первом запуске («кэш Далвика» — это вот они), обеспечивая значительное ускорение при повторных вызовах, а ART — при установке. Впрочем, даже эта JIT, Just In Time, то есть «на лету», компиляция байт-кода в машинный появилась лишь в Android 2.2, а до того всё было на одном интерпретаторе. То есть при Dalvik приложения быстрее устанавливаются, но задают жару системе при первом старте. При ART приложения заметно, прям сильно заметно, дольше устанавливаются, зато запускаются шустрее и не создают таких нагрузок при первом старте. На самом деле различий больше, но нас они особо не касаются. Лично мне знание всех этих различий ни разу не пригодилось в работе.

Так вот, monitor, который запускается файлом monitor.bat, представляет собой, кроме всего прочего, графическую оболочку для logcat. Что это такое, я расскажу позже. Здесь нам важно, что в этой оболочке мы можем искать нужные строки, фильтровать их, отслеживать поведение продукта, да ещё пусть и с примитивной, но всё-таки подсветкой. Возможностей у monitor больше, но они либо практически бесполезны, если у вас есть более одного устройства, либо слишком хардкорны для ознакомительной лекции.

Monkeyrunner

Uiautomatorviewer

Это полезный инструмент, облегчающий написание грей бокс автотестов. Что такое White box, Black box и Gray box тестирование?

• White box — мы знаем о приложении всё, при желании даже в код можем заглянуть. Более того, наше тестовое приложение может обращаться напрямую к тестируемому приложению, топая грязными ногами в его песочнице
• Black box — мы не знаем о приложении ничего. Мы люди простые — мы видим поле ввода, мы вводим туда данные. Ноль, единицу, огромное число, отрицательное число, число с десятичной точкой, число с десятичной запятой, текст, символы юникода, null’ы, скриптовые сценарии, вставляем из буфера обмена сочинения Льва Толстого, картинки, музыкальные файлы, ставим символ юникода, чтобы текст вводился справа налево… В общем — любимое развлечение при типичном исследовательском тестировании
• Gray box — мы кое-что знаем о приложении, но особо с этим сделать ничего не можем. К примеру, мы знаем, как и почему текст меняется при нажатии на кнопку, но программно именно на эту кнопку нажать не можем. «Именно на эту» — это обращение уровня findViewById(R.id.btnPressMeButton), а не уровня «кнопка, которая лежит вот на этом экране, но не первая, а вторая». Когда вы пытаетесь своей маме по телефон объяснить, как сделать скриншот, это вот оно. Вы знаете, как это происходит, вы точно знаете, что должно получиться на каждом из шагов, но сами этого сделать не можете

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

• Мы подключаем устройство к компьютеру или же запускаем эмулятор
• Запускаем приложение и просим этот инструмент собрать данные обо всём, что он «видит»

Инструмент очень подробно разбирает всё приложение на элементарные элементы и показывает все доступные их свойства. В итоге мы можем своим автотестам обращаться чётко к нужным ресурсам вне зависимости от того, на каком устройстве это приложение было запущено. Что ещё ценно, этот инструмент позволяет сохранить данные о разобранных экранах. Мы можем взять устройство на время, быстро сохранить нужные экраны нужных приложений и вернуть его. А дальше писать сценарий автотеста, посматривая в сохранённые данные.
Чем же это хуже тестирования белого ящика? Тем, что это всё так сладко только в теории. На практике же графический интерфейс приложения может быть построен таким образом, что на нём будет множество «одинаковых» элементов.

Рис. 2. Так uiautomatorviewer «видит» экран настроек режима разработчика (правая верхняя треть) и данные конкретного переключателя, по которым его можно попытаться найти программно (правая нижняя треть)

На скриншоте типичный пример, когда обратиться к конкретному элементу можно, но это уже выходит за рамки «охохо, сейчас мы тут всё быстренько автоматизируем». У переключателя тот же айди ресурса, что и у всех других переключателей. Нет, в R.java (в этом файле перечислены вообще все ресурсы, какие они есть в приложении) у них разные айди, но снаружи этого не видно.
Теперь, чтобы переключить конкретно этот переключатель, нужно рекурсивно перебирать лайауты (это, грубо говоря, форма с пазами, в которые все элементы интерфейса вставляются, а форма уже «следит», чтобы из пазов ничего не уезжало) и по косвенным признакам находить нужный, чтобы уже в нём забраться внутрь и щёлкнуть тумблером. Либо же сразу обратиться к нужному лайауту по его индексу (здесь он имеет индекс 6), внутри которого выбрать дочерний с индексом 1, внутри которого щёлкнуть тумблером.

В первом случае кода будет намного больше, зато небольшие перетасовки интерфейса не сломают автотест, потому что ориентируется он по косвенным признакам (скажем, читает текст и сравнивает с эталонным), однако это уже слабо подходит для тестирования локализаций (потому что в локализациях тексты, понятное дело, меняются). Во втором случае кода совсем мало, можно даже в пару строк уложиться, зато просто перестановка двух вьюх (View здесь — это каждый из элементов интерфейса: каждая кнопка, каждая надпись, каждый переключатель — всё это самостоятельные вьюхи) относительно друг друга полностью сломает автотест. Зато этот метод идеален для тестирования локализаций, потому что для локализаций интерфейс меняют очень редко и нужно, как правило, проверять именно влезание надписей и что эти надписи вообще правильные. А это, между прочим, uiautomatorviewer умеет! Просто потому что он получает ровно те строки, которые видны. То есть если строка вылезает за пределы экрана, вылезшую часть он не «прочтёт».

Build Tools

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

Источник