Android build xml src

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…

Источник

Qt Documentation

Contents

This article describes the technical steps required to deploy a Qt application to an Android device.

Android Application Bundle

Applications on Android can be packaged in two ways; either as Application Package (APK) or Android App Bundle (AAB). Both are ZIP files which follow a predefined directory structure. The difference between the two is that APK files can be deployed and executed on a device, whereas AAB is intended to be interpreted by the Google Play store and is used to generate APK files for different device architectures.

For testing the application locally, the APK format is the most appropriate, as this can be uploaded directly to the device and run. For distribution to the Google Play store, it is recommended to use AAB instead, which has a similar layout. The added convenience of AAB is that you can include all target ABIs in the same bundle without increasing the size of the actual package downloaded by your users. When using AAB, the Google Play store generates optimized APK packages for the devices issuing the download request and automatically signs them with your publisher key.

For more information on the AAB format, see the Android App Bundles.

In either case, the application bundle is generated from a specific directory structure that contains the .so file of your code, as well as all Qt’s dependencies needed by your application. In addition, any .jar files, Java code, assets, resources and .xml files are included.

Generating the Application Bundle

It is recommended to use Qt Creator or the Makefile created by qmake or CMake to create the application bundle.

All the steps described here are automatically handled by the build script and the androiddeployqt deployment tool, which are run by Qt Creator by default.

Note: If you prefer building Android packages from the command line, see Building the Android Application.

Android Package Templates

The default templates used by Qt are found in $Qt_install_dir/src/android/templates . The first step of making a custom package is to copy these files into an empty directory, for example android , under your project. Then, you need to define that path in your project’s .pro file, using the variable ANDROID_PACKAGE_SOURCE_DIR:

Qt Creator copies the package templates to your Android build directory ($ANDROID_BUILD_DIR=$BUILD_DIR/android-build) into your project build directory ($BUILD_DIR). If you want to build from the command line, use the following after running qmake or CMake :

The previous command copies the application’s binaries and resources into the $ANDROID_BUILD_DIR. The build directory acts now as the packaging directory, which the application bundle is created from. The main parts of the package templates are described in the following sections.

AndroidManifest.xml

The AndroidManifest.xml file gives detailed meta-information about your application. This information is used to customize your application bundle and by the target device to decide which features to enable, the default orientation of the application, and so on. In addition, it’s used by the Google Play Store for information on the version code, device support, package name, and lots more.

For more information about the AndroidManifest.xml , see Android Manifest documentation.

The default manifest contains some special parameters used by Qt to set up the application and load all the necessary libraries for Qt. When you are customizing your own Android manifest, make sure that it contains these parameters. For that reason, it’s recommended to start with the default templates, then customize on top of that. The androiddeployqt tool replaces content in the templates with the correct values. The parts that are filled by androiddeployqt have the value as «— %%INSERT_VALUE%% —«, as in:

The Android Manifest is also used to define Android Services, and custom Android Activities.

Java Code

Under $Qt_install_dir/src/android/java/src/org/qtproject/qt5/android/bindings/ are the files comprising the Java code of the Android application. This Java code is compiled under $ANDROID_BUILD_DIR and added to the application bundle. The regular Android application launcher is a Java process, so Qt applications have a Java-based entry point. The code in here will load the required Qt libraries, based on the meta-information given in Manifest file.

After loading the libraries, the Java code will call into the application’s native main() function on a new thread and the application will launch. At this point, the Java code in the templates is used to delegate events from Android into Qt.

One thing to note about the files in this directory is that they can contain code specific to certain Android versions. Based on the minimum required Android API level of your application it might be necessary to remove some of this code. This is done automatically by androiddeployqt and Qt Creator during packaging.

If your minimum Android API level is 20 or lower, the code below is removed before building, since it’s not a supported API on Android API level 20. However, if your minimum API level is 21 or higher, it is left in:

Resources

Under the $Qt_instal_dir/src/android/templates/res/ folder are Android resources that can be accessed from the AndroidManifest.xml and Java code used by all Qt applications.

libs.xml

This file can be found at $Qt_instal_dir/src/android/templates/res/values/libs.xml . One of the files containing meta information about the deployment of the application is libs.xml . It consists of the following values:

• bundled_libs : Libraries in the package’s library folder which should be loaded on start-up. Library names should be specified without the lib prefix and .so suffix.
• qt_libs : Qt libraries which should be loaded on start-up. When bundled deployment is used, these are expected to be found inside the APK ‘s library folder.

Note: Ministro is no longer maintained.

strings.xml

This file can be found at $Qt_instal_dir/src/android/java/res/values/strings.xml . The strings.xml file contains strings used by the AndroidManifest.xml and by the deployment mechanisms.

In particular, the application name and the name of the application binary can be specified here. There are also strings that contain additional libraries that should be loaded and JAR files which should be included in the class path.

Gradle Files

The main Gradle build file can be found at $Qt_instal_dir/src/android/templates/build.gradle . This file is required by the Gradle build system used by Android to generate the application’s APK. For more information, see Android Build Configuration Files.

Customizing the Package Templates

Resouces

Put any resources used by your application under $ANDROID_PACKAGE_SOURCE_DIR/res/ . A typical example of resources customization which should be placed here are the icons used by the application launcher to show your application.

Custom Java Code

Place any Java code under the path $ANDROID_PACKAGE_SOURCE_DIR/src/ . Any code here can be used with your application, for example you can call Java methods from within Qt code. For more information, see Qt JNI Messenger Example.

When using Qt Creator, add the Java files to your project using DISTFILES, so they are visible under the project files.

Assets

You can place any assets that are intended to be accessed by Java code under $ANDROID_PACKAGE_SOURCE_DIR/assets/ . For more information on using assets with Qt, see Porting to Android.

Note: Using The Qt Resource System entails having .qrc files bundled in the .so files which must be unpacked first to be loaded by the linker, while the Android assets are compressed in the .apk and can be directly used in your application. That means using the Android assets can take up less space, but it’s not a cross-platform solution with Qt.

Android Libraries

Under $ANDROID_PACKAGE_SOURCE_DIR/libs in your custom package directory, it’s possible to place libraries that should be included in the application bundle. JAR libraries should be placed directly under $ANDROID_PACKAGE_SOURCE_DIR/libs/ , while shared libraries should be put in a subdirectory named after the target ABI of the libraries. The supported ABIs are: armeabi-v7a, arm64-v8a, x86, x86_64.

Building the Android Application

Starting from Qt 5.14.0, you may use the «aab» or «apk» build targets from the Makefile directly to build the application bundle. Use the following command to generate an AAB:

Or to generate the APK:

Under the hood, your Qt code is built and copied to the $ANDROID_BUILD_DIR, then Gradle is used to build the Java code and package the application. If an APK intended for release is built, then it should be signed with jarsigner and aligned with zipalign . For more information on signing the package with Qt Creator, see Signing Android packages.

androiddeployqt

Building an application package is complex, so Qt comes with a tool which handles the work for you. The steps described in this document so far are handled automatically by this tool. This section describes some of the steps that this tool facilitates.

Prerequisites Before Running androiddeployqt

Before running the tool manually, you need to run qmake or CMake on your project to generate Makefiles and a JSON file (i.e. android-project-deployment-settings.json ) containing important settings used by androiddeployqt .

Note: It is not recommended to modify the androiddeployqt JSON file.

To prepare the build for androiddeployqt, it is recommended to build your project in a separate directory. Run the following commands:

Command Line Arguments

The only required command line argument when running the tool is —output . Other command line arguments are optional but useful. Here’s a quick overview. More information is available by passing the —help argument to androiddeployqt.

Argument	Brief Description
—output	Specifies the destination of the final package. Set this to $ANDROID_BUILD_DIR , that is the build directory where you installed your application binaries.
—input	This allows you to specify the generated JSON settings file. androiddeployqt will try to guess the file name based on the current working directory.
—aab	Generate an Android Application Bundle, rather than an APK. Note that this invalidates some of the other arguments, such as —install .
—deployment	Specify this to pick a different deployment mechanism than the default.
—install	Specify this to install the finished package on the target device or emulator. Note that if a previous version of the package is already installed, it will be uninstalled first, removing any data it might have stored locally.
—device	Specify the ID of the target device or emulator as reported by the adb tool. If an ID is specified, it will be passed to all calls to adb . If it is unspecified, no particular device or emulator will be requested by adb , causing it to pick a default instead.
—android-platform

The SDK platform used for building the Java code of the application. By default, the latest available platform is used. —release Specify this to create a release package instead of a debug package. With no other arguments, release packages are unsigned and cannot be installed to any device before they have been signed by a private key. —sign

Sign the resulting package. Specifying this also implies —release . The URL of the keystore file and the alias of the key have to be specified. In addition, there are a number of options that can be specified which are passed through to the jarsigner tool. Pass —help to androiddeployqt for more information. —jdk

Specify the path to the Java Development Kit. This is only required for signing packages, as it is only used for finding the jarsigner tool. If it is unspecified, then androiddeployqt will attempt to detect jarsigner , either using the JAVA_HOME environment variable, or on the PATH . —verbose Specify this to output more information about what androiddeployqt is doing. —help Prints the help for the tool.

With a project named project , to directly build the application package with androiddeployqt without deploying it the device, run the following:

To deploy the built package to the device:

Dependencies Detection

Qt comes with a number of plugins which are loaded at run-time when they are needed. These can handle anything from connecting to SQL databases to loading specific image formats. Detecting plugin dependencies is impossible as the plugins are loaded at run-time, but androiddeployqt tries to guess such dependencies based on the Qt dependencies of your application. If the plugin has any Qt dependencies which are not also dependencies of your application, it will not be included by default. For instance, in order to ensure that the SVG image format plugin is included, you will need to add Qt SVG module to your project for it to become a dependency of your application:

If you are wondering why a particular plugin is not included automatically, you can run androiddeployqt with the —verbose option to get the list of missing dependencies for each excluded plugin. You can achieve the same in Qt Creator by ticking the Verbose output check box in the Projects > Build Steps > Build Android APK > Advanced Actions.

It’s also possible to manually specify the dependencies of your application. For more information, see ANDROID_DEPLOYMENT_DEPENDENCIES qmake variable.

Android-specific qmake Variables

Unless the project has special requirements such as third party libraries, it should be possible to run androiddeployqt on it with no modifications and get a working Qt for Android application.

There are two important environment variables used by Qt:

• ANDROID_SDK_ROOT : specifies the path to the Android SDK used for building the application. The Android SDK contains the build-tools, Android NDK, and Android toolchains.
• ANDROID_NDK_ROOT : specifies the path to the Android NDK used to build the application. It is not recommended to hard-code this path, since different Qt for Android versions can depend on different Android NDK versions.

Note: Qt Creator sets these variables by default.

There are a set of qmake variables that can be used to tailor your package. At some point during development, you will most likely want to look into these variables to customize your application.

Here is a list of some variables that are particularly interesting when making Android applications:

Also, the following qmake variables are primarily useful when writing a Qt module, and not normal applications:

Note: This list of variables can also be used with CMake.

Deployment in Qt Creator

Qt Creator runs the androiddeployqt tool by default, and provides easy and intuitive user interfaces to specify many of the options. For more information, see Qt Creator: Deploying Applications to Android Devices.

В© 2021 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.

Источник