Create android application without gradle

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…

Источник

The Application Plugin

The Application plugin facilitates creating an executable JVM application. It makes it easy to start the application locally during development, and to package the application as a TAR and/or ZIP including operating system specific start scripts.

Applying the Application plugin also implicitly applies the Java plugin. The main source set is effectively the “application”.

Applying the Application plugin also implicitly applies the Distribution plugin. A main distribution is created that packages up the application, including code dependencies and generated start scripts.

Building JVM applications

To use the application plugin, include the following in your build script:

The only mandatory configuration for the plugin is the specification of the main class (i.e. entry point) of the application.

You can run the application by executing the run task (type: JavaExec). This will compile the main source set, and launch a new JVM with its classes (along with all runtime dependencies) as the classpath and using the specified main class. You can launch the application in debug mode with gradle run —debug-jvm (see JavaExec.setDebug(boolean)).

Since Gradle 4.9, the command line arguments can be passed with —args . For example, if you want to launch the application with command line arguments foo —bar , you can use gradle run —args=»foo —bar» (see JavaExec.setArgsString(java.lang.String).

If your application requires a specific set of JVM settings or system properties, you can configure the applicationDefaultJvmArgs property. These JVM arguments are applied to the run task and also considered in the generated start scripts of your distribution.

If your application’s start scripts should be in a different directory than bin , you can configure the executableDir property.

Building applications using the Java Module System

Gradle supports the building of Java Modules as described in the corresponding section of the Java Library plugin documentation. Java modules can also be runnable and you can use the application plugin to run and package such a modular application. For this, you need to do two things in addition to what you do for a non-modular application.

First, you need to add a module-info.java file to describe your application module. Please refer to the Java Library plugin documentation for more details on this topic.

Second, you need to tell Gradle the name of the module you want to run in addition to the main class name like this:

That’s all. If you run your application, by executing the run task or through a generated start script, it will run as module and respect module boundaries at runtime. For example, reflective access to an internal package from another module can fail.

The configured main class is also baked into the module-info.class file of your application Jar. If you run the modular application directly using the java command, it is then sufficient to provide the module name.

You can also look at a ready made example that includes a modular application as part of a multi-project.

Building a distribution

A distribution of the application can be created, by way of the Distribution plugin (which is automatically applied). A main distribution is created with the following content:

Table 1. Distribution content

All runtime dependencies and main source set class files.

Start scripts (generated by startScripts task).

Static files to be added to the distribution can be simply added to src/dist . More advanced customization can be done by configuring the CopySpec exposed by the main distribution.

By specifying that the distribution should include the task’s output files (see more about tasks), Gradle knows that the task that produces the files must be invoked before the distribution can be assembled and will take care of this for you.

You can run gradle installDist to create an image of the application in build/install/projectName . You can run gradle distZip to create a ZIP containing the distribution, gradle distTar to create an application TAR or gradle assemble to build both.

Customizing start script generation

The application plugin can generate Unix (suitable for Linux, macOS etc.) and Windows start scripts out of the box. The start scripts launch a JVM with the specified settings defined as part of the original build and runtime environment (e.g. JAVA_OPTS env var). The default script templates are based on the same scripts used to launch Gradle itself, that ship as part of a Gradle distribution.

The start scripts are completely customizable. Please refer to the documentation of CreateStartScripts for more details and customization examples.

Tasks

The Application plugin adds the following tasks to the project.

Depends on: classes

Starts the application.

Creates OS specific scripts to run the project as a JVM application.

Depends on: jar , startScripts

Installs the application into a specified directory.

Depends on: jar , startScripts

Creates a full distribution ZIP archive including runtime libraries and OS specific scripts.

Depends on: jar , startScripts

Creates a full distribution TAR archive including runtime libraries and OS specific scripts.

Application extension

The Application Plugin adds an extension to the project, which you can use to configure its behavior. See the JavaApplication DSL documentation for more information on the properties available on the extension.

You can configure the extension via the application <> block shown earlier, for example using the following in your build script:

Источник

Create a Basic Android App without an IDE

Virtually every Android tutorial uses Android Studio to create and develop an app. This isn’t great for learning since you don’t see how things work, namely

• The components that make up an Android Studio project
• How builds are setup and configured
• What parts comprise the source

Software development is about files and in this tutorial we’re going to go through every file in a basic Android project – first by examining what Android Studio outputs and then by building up an Android project from scratch. We won’t assume any previous Android experience, just a little Java.

Note: I’ll be doing this on Windows but most instructions should work on other platforms.

Break Down Your Android Studio Project

This is what Android Studio creates when you start a completely bare project.

The first thing to notice is that most files involve Gradle, the system for configuring and executing builds. What do we have without any Gradle files ?

Only three folders and three files. Clearly the main complexity in Android projects is the build system.

Let’s look at what files are not included in source control by looking at .gitignore.

So MyApplication.iml isn’t important. If you Google what iml files are for you will see they are used by Android Studio and can be regenerated from the configurations in .idea/ .

Also, local.properties aren’t important either, as well as build/ . What does that leave us with? Just the app/ folder and some files in .idea/ which is where IntelliJ (which Android Studio is built on) stores configuration files.

Inside the app folder you’ll find two directories and three files:

• libs/ , which is empty
• src/ , which isn’t
• .gitignore
• build.gradle
• ProGuard

ProGuard helps shrink your final APK by removing unused libraries. You don’t need this file (it’s actually all commented out). The .gitignore is use for source control, if you didn’t know that already. So it’s just src/ and build.gradle that are important.

src/ contains your Java source code, the resources you use like layouts and configuration files, and the AndroidManifest which tells Android what your app is. And build.gradle tells Gradle how to convert your source into an APK using the Gradle Android plugin.

To see all of this in action, let’s get to building our code base from the ground up, first installing the SDK, then initializing gradle, onto converting to an Android build, and finally writing the app code.

Get Started with the Android SDK

For this project, you’ll need to download the Android SDK. This is just a ZIP file. Go to the normal install page and scroll right to the bottom at Command Line Tools. There you’ll find the zips which are only around 150MB. Extract and set your ANDROID_SDK_ROOT environment variable to the extracted location.

And that’s it! Gradle should pick this up automatically. (Note: Gradle stores the SDK location in the local.properties file, which as we saw before isn’t saved to source control).

Initialize Gradle

To start our project from scratch we initialize a folder using Gradle. First install Gradle. I downloaded the binary-only version from the Manual section and added the bin folder to my PATH .

The gradle command should now work from your command line. Note: you need to have Java 7 or higher installed as well. Here is what you see when you initialise an empty folder with gradle init .

See how all these files are in the Android Studio project output ? For a great explanation of what these files are see the Gradle create build guide.

Create an Android Build

Next we need to set up our project to build Android. The first step is to change settings.gradle to simply include the app module (which is just a folder).

Next, put the following into your root build.gradle .

This primarily defines where to download our Gradle libraries from.

Next, create the /app directory and place the following into app/build.gradle .

This uses the Android Gradle plugin (com.android.application) and sets some values like the SDK version and Proguard (which optimizes our output size). Also, in the dependencies section it gives any libraries we want to import (here we import two, both used in building our interface later).

Now create app/src/main/res/values/styles.xml which we’ll use to set our app’s theme.

Finally put the following into app/src/main/AndroidManifest.xml :

This defines the package, label and main activity of our app.

Now when you run gradlew build you should see BUILD SUCCESSFUL. And in app/build/outputs/apk/debug you should see app-debug.apk . You’ve just set up an Android build from scratch!

To deploy this simply say gradlew installDebug with your phone plugged in (and USB Debugging enabled). You should then see a new app called Demo App. It will crash when you run it because you haven’t written any Java code yet!

Write the Java Application

With your build set up next we need to write the Java. We only need two files for this: the main activity Java file, and the layout XML.

Put the following into app/src/main/java/com/example/karl/myapplication/MainActivity.java .

It just creates a new Activity (a core process-like idea in Android) and sets the view to a layout in the Resources folder.

Put this into app/src/main/res/layout/activity_main.xml .

This just creates a “Hello World!” message center-screen.

Now run gradlew build and you should see BUILD SUCCESSFUL again. Use gradlew installDebug to install to your phone and you should see the following:

You’ve just made a working Android app with nothing but a text editor :).

Add Authentication with Okta

Most modern apps require some level of security, so it’s worthwhile to know how to build authentication simply and easily. For this, we’ll use the OktaAppAuth wrapper library.

Why Okta?

At Okta, our goal is to make identity management a lot easier, more secure, and more scalable than what you’re used to. Okta is a cloud service that allows developers to create, edit, and securely store user accounts and user account data, and connect them with one or multiple applications. Our API enables you to:

• Authenticate and authorize your users
• Store data about your users
• Perform password-based and social login
• Secure your application with multi-factor authentication
• And much more! Check out our product documentation

Are you sold? Register for a forever-free developer account, and when you’re done, come on back so we can learn more about building secure mobile apps!

Authentication in Java

Create a new Activity called LoginActivity.java and place it in the same folder as MainActivity.

This initializes the OktaAppAuth object and handles the Success or Failure conditions. Next, change AndroidManifest.xml to point to LoginActivity instead of MainActivity .

Now add the following to the defaultConfig section of app/build.config .

Finally, add the following to the same file’s dependencies:

That should build and deploy. You can use logcat to see what is happening in the background. Looking at the source code for the main library class we see the tag we need to use is “OktaAppAuth”.

Right after trying to create the service we get a Configuration was invalid error. We need to connect our app to an Okta account.

Connect to Okta for Authentication

Since you already have an Okta developer account, you can move right on to configuration. From the developer console select the Applications tab and then New Application. Select Native and click next. The fields should auto-populate correctly. The most important part is the redirect URL. Click done.

On the Assignments tab, click the Assign dropdown and choose Assign to Groups. Click Assign next to the Everyone group. Now, anyone in your Okta organization will be able to authenticate to the application.

You now should have enough to populate app/src/main/res/raw/okta_app_auth_config.json .

Change the appAuthRedirectScheme field in app/build.gradle to the base of your redirect URI, e.g. «appAuthRedirectScheme»: «» .

Configuration should now be complete! If you gradlew installDebug and do the logcat as before you should no longer be seeing the error when you open the app, and should see a message saying Warming up browser instance for auth request .

Set Up Your Login Page

Let’s add a button and progress bar to our login page. Create app/src/main/res/layout/activity_login.xml.

Initially the button is hidden. We’ll show that (and hide the progress bar) once Okta has finished initializing. To do that put the following into the onSuccess() method in LoginActivity.java .

Lastly, before the Okta init set the layout to the XML we just created.

When you installDebug and run the app you should see a title with a login button.

Wire Up Login

To capture the login details, i.e. username/password, we can use a default page. First create the landing page for when we are authorized in AuthorizedActivity.java :

We attach a listener to the button logging us out and taking us back to the login page. Now in activity_authorized.xml put

As with the login page it’s just a title with a button. Wire up the login button in LoginActivity.java by placing the following at the end of the onCreate method.

Now when you click the Login button you should see an Okta login page asking for your details.

If you enter in user details which are correct for the Application we made previously (your Okta portal credentials should work) you are taken to an authorized page.

Clicking the logout button should take you back to our first screen.

And that’s it for authorization!

Most people think you need Android Studio to make an Android app. In this post, you shattered that notion and built an Android app from scratch. With some configuration and a little code, you integrated authentication into your app with the OktaAppAuth library. Then you created a view that only authenticated users can see. From here, you can build out the rest of your app safe in the knowledge that authentication is handled, thanks to Okta.

Learn More about Java and Secure App Development

I hope you’ve enjoyed this tutorial on how to build a basic Android app without an IDE. You can find the example created in this tutorial on GitHub at https://github.com/oktadeveloper/okta-android-example.

We’ve written some other cool Spring Boot and React tutorials, check them out if you’re interested.

If you have any questions, please don’t hesitate to leave a comment below, or ask us on our Okta Developer Forums. Follow us on Twitter @oktadev if you want to see more tutorials like this one!

Okta Developer Blog Comment Policy

We welcome relevant and respectful comments. Off-topic comments may be removed.

Источник

Location	Content