Android apps can be written using Kotlin, Java, and C++ languages

The Android SDK tools compile your code along with any data and resource
files into an APK, an Android package, which is an archive file with
an .apk suffix

One APK file contains all the contents of an Android app and is the file that
Android-powered devices use to install the app.

 The Android operating system is a multi-user Linux system in which each

app is a different user.
 By default, the system assigns each app a unique Linux user ID (the ID is
used only by the system and is unknown to the app). The system sets
permissions for all the files in an app so that only the user ID assigned to that
app can access them.
 Each process has its own virtual machine (VM), so an app's code runs in
isolation from other apps.
 By default, every app runs in its own Linux process. The Android system
starts the process when any of the app's components need to be executed, and
then shuts down the process when it's no longer needed or when the system
must recover memory for other apps.

Gradle Build system

Configure your build

The Android build system compiles app resources and source code, and
packages them into APKs that you can test, deploy, sign, and distribute.
Android Studio uses Gradle, an advanced build toolkit, to automate and manage
the build process, while allowing you to define flexible custom build
configurations.

Each build configuration can define its own set of code and resources, while
reusing the parts common to all versions of your app. The Android plugin for
gradle works with the build toolkit to provide processes and configurable
settings that are specific to building and testing Android applications.

Gradle and the Android plugin run independent of Android Studio. This means
that you can build your Android apps from within Android Studio, the
command line on your machine, or on machines where Android Studio is not
installed (such as continuous integration servers).

If you are not using Android Studio, you can learn how to build and run your
app from the command line.

The output of the build is the same whether you are building a project from the
command line, on a remote machine, or using Android Studio.

Note: Because Gradle and the Android plugin run independently from Android
Studio, you need to update the build tools separately. Read the release notes to
learn how to update Gradle and the Android plugin.

The flexibility of the Android build system enables you to perform custom build
configurations without modifying your app's core source files. This section
helps you understand how the Android build system works, and how it can help
you customize and automate multiple build configurations. If you simply want
to learn more about deploying your app, see Building and Running from
Android Studio. To start creating custom build configurations right away using
Android Studio, see Configuring Build Variants.

The build process

The build process involves many tools and processes that convert your project
into an Android Application Package (APK). The build process is very flexible,
so it's useful to understand some of what is happening under the hood.
 Figure 1. The build process of a typical Android app module.

The build process for a typical Android app module, as shown in figure 1,
follows these general steps:

1. The compilers convert your source code into DEX (Dalvik Executable)
files, which include the byte code that runs on android devices and everything
else into compiled resources.
2. The APK Packager combines the DEX files and compiled resources into
a single APK. Before your app can be installed and deployed onto an Android
device, however, the APK must be signed.
3. The APK Packager signs your APK using either the debug or release
keystore:
4. If you are building a debug version of your app, that is, an app you intend
only for testing and profiling, the packager signs your app with the debug key
store. Android Studio automatically configures new projects with a debug key
store.
If you are building a release version of your app that you intend to release
externally, the packager signs your app with the release key store. To create a
release key store, read about signing your app in Android Studio.
Before generating your final APK, the packager uses the zipalign tool to
optimize your app to use less memory when running on a device.

At the end of the build process, you have either a debug APK or release APK of
your app that you can use to deploy, test, or release to external users.

Custom build configurations

Gradle and the Android plugin help you configure the following aspects of your
build:

Build Types:

Build types define certain properties that Gradle uses when building and
packaging your app, and are typically configured for different stages of
your development lifecycle. For example, the debug build type enables
debug options and signs the APK with the debug key, while the release
build type may shrink, obfuscate, and sign your APK with a release key
for distribution. You must define at least one build type in order to build
your app—Android Studio creates the debug and release build types by
default. To start customizing packaging settings for your app

Product Flavors:

Product flavors represent different versions of your app that you may
release to users, such as free and paid versions of your app. You can
customize product flavors to use different code and resources, while
sharing and reusing the parts that are common to all versions of your app.
Product flavors are optional and you must create them manually.

Build Variants:

A build variant is a cross product of a build type and product flavor, and
is the configuration Gradle uses to build your app. Using build variants,
you can build the debug version of your product flavors during
development, or signed release versions of your product flavors for
distribution. Although you do not configure build variants directly, you
 do configure the build types and product flavors that form them. Creating
additional build types or product flavors also creates additional build
variants.

Manifest Entries:

You can specify values for some properties of the manifest file in the
build variant configuration. These build values override the existing
values in the manifest file. This is useful if you want to generate multiple
APKs for your modules where each of the apk files has a different
application name, minimum SDK version, or target SDK version.

Dependencies:

The build system manages project dependencies from your local

filesystem and from remote repositories. This prevents you from having
to manually search, download, and copy binary packages of your
dependencies into your project directory

Signing:

The build system enables you to specify signing settings in the build
configuration, and it can automatically sign your APKs during the build
process. The build system signs the debug version with a default key and
certificate using known credentials to avoid a password prompt at build
time. The build system does not sign the release version unless you
explicitly define a signing configuration for this build

ProGuard:

The build system enables you to specify a different ProGuard rules file
for each build variant. The build system can run ProGuard to shrink and
obfuscate your classes during the build process.

Multiple APK Support:

The build system enables you to automatically build different APKs that
each contain only the code and resources needed for a specific screen
density or Application Binary Interface (ABI)
Build configuration files
Creating custom build configurations requires you to make changes to one or
more build configuration files, or build gradle files. These plain text files use
Domain Specific Language (DSL) to describe and manipulate the build logic
using Groovy, which is a dynamic language for the Java Virtual Machine
(JVM). You don’t need to know Groovy to start configuring your build because
the Android plugin for Gradle introduces most of the DSL elements you need.
To learn more about the Android plugin DSL, read the DSL reference
documentation.

When starting a new project, Android Studio automatically creates some of

these files for you, as shown in figure 2, and populates them based on sensible
defaults.

Figure 2. The default project structure for an Android app module.

There are a few Gradle build configuration files that are a part of the standard
project structure for an Android app. Before you can start configuring your
build, it is important to understand the scope and purpose of each of these files,
and the basic DSL elements they should define.

The Gradle settings file

The settings.gradle file, located in the root project directory, tells Gradle which
modules it should include when building your app. For most projects, the file is
simple and only includes the following:

include ‘:app’

However, multi-module projects need to specify each module that should go

into the final build.

The top-level build file

The top-level build.gradle file, located in the root project directory, defines
build configurations that apply to all modules in your project. By default, the
top-level build file uses the buildscript block to define the
Gradle repositories and dependencies that are common to all modules in the
project. The following code sample describes the default settings and DSL
elements you can find in the top-level build.gradle after creating a new project.

The module-level build file

The module-level build.gradle file, located in each project/module/ directory,

allows you to configure build settings for the specific module it is located in.
Configuring these build settings allows you to provide custom packaging
options, such as additional build types and product flavors, and override settings
in the main/ app manifest or top-level build.gradle file.

This sample Android app module build.gradle file outlines some of the basic
DSL elements and settings that you should know.

Gradle properties files

Gradle also includes two properties files, located in your root project directory,
that you can use to specify settings for the Gradle build toolkit itself:

gradle.properties

This is where you can configure project-wide Gradle settings, such as the
Gradle daemon's maximum heap size. For more information, see The
Build Environment.

local.properties

Configures local environment properties for the build system, such as the
path to the SDK installation. Because the content of this file is
automatically generated by Android Studio and is specific to the local
developer environment, you should not modify this file manually or
check it into your version control system.

Syncing project with Gradle files

When you make changes to the build configuration files in your project,
Android Studio requires that you sync your project files so that it can import
your build configuration changes and run some checks to make sure your
configuration won't create build errors.

To sync your project files, click Sync Now in the notification bar that appears
when you make a change, as shown in figure 3, or click Sync Project from
the menu bar. If Android Studio notices any errors with your configuration, for
example, your source code uses API features that are only available in an API
level higher than your compileSdkVersion, the Messages window appears to
describe the issue.

Figure 3. Syncing the project with build configuration files in Android Studio.

Source sets
 Android Studio logically groups source code and resources for each module
into source sets. A module’s main/ source set includes the code and resources
used by all its build variants. Additional source set directories are optional, and
Android Studio does not automatically create them for you when you configure
new build variants. However, creating source sets, similar to main/, helps
organize files and resources that Gradle should only use when building certain
versions of your app:

src/main/

This source set includes code and resources common to all build variants.

src/buildType/

Create this source set to include code and resources only for a specific
build type.

src/productFlavor/

Create this source set to include code and resources only for a specific
product flavor.

Note: If you configure your build to combine multiple product flavors,

you can create source set directories for each combination of product
flavors between the flavor
dimensions:src/productFlavor1ProductFlavor2/

src/productFlavorBuildType/

Create this source set to include code and resources only for a specific
build variant.

For example, to generate the "fullDebug" version of your app, the build system
merges code, settings, and resources from following source sets:

 src/fullDebug/ (the build variant source set)

 src/debug/ (the build type source set)
 src/full/ (the product flavor source set)
 src/main/ (the main source set)
Note: When you create a new file or directory in Android Studio, using the File
> New menu options, you can create it for a specific source set. The source sets
you can choose from are based on your build configurations, and Android
Studio automatically creates the required directories if they don't already exist.

If different source sets contain different versions of the same file, Gradle uses
the following priority order when deciding which file to use (source sets on the
left override the files and settings of source sets to the right):

build variant > build type > product flavor > main source set > library
dependencies

This allows Gradle to use files that are specific to the build variant you are
trying to build while reusing activities, application logic, and resources that are
common to other versions of your app. When merging multiple manifests,
Gradle uses the same priority order, so each build variant can define different
components or permissions in the final manifest.

Android Debug Bridge (adb)

Android Debug Bridge (adb) is a versatile command-line tool that lets you
communicate with a device. The adb command facilitates a variety of device
actions, such as installing and debugging apps, and it provides access to a Unix
shell that you can use to run a variety of commands on a device. It is a client-
server program that includes three components:

A client, which sends commands. The client runs on your development

machine. You can invoke a client from a command-line terminal by issuing an
adb command.
A daemon (adbd), which runs commands on a device. The daemon runs as a
background process on each device.
A server, which manages communication between the client and the daemon.
The server runs as a background process on your development machine.

adb is included in the Android SDK Platform-Tools package. You can

download this package with the SDK Manager, which installs it
at android_sdk/platform-tools/. Or if you want the standalone Android SDK
Platform-Tools package, you can download it here.

How adb works

When you start an adb client, the client first checks whether there is an adb
server process already running. If there isn't, it starts the server process. When
the server starts, it binds to local TCP port 5037 and listens for commands sent
from adb clients—all adb clients use port 5037 to communicate with the adb
server.

The server then sets up connections to all running devices. It locates emulators
by scanning odd-numbered ports in the range 5555 to 5585, the range used by
the first 16 emulators. Where the server finds an adb daemon (adbd), it sets up a
connection to that port. Note that each emulator uses a pair of sequential ports
— an even-numbered port for console connections and an odd-numbered port
for adb connections. For example:

Emulator 1, console: 5554

Emulator 1, adb: 5555
Emulator 2, console: 5556
Emulator 2, adb: 5557
and so on...

As shown, the emulator connected to adb on port 5555 is the same as the
emulator whose console listens on port 5554.

Once the server has set up connections to all devices, you can use adb
commands to access those devices. Because the server manages connections to
devices and handles commands from multiple adb clients, you can control any
device from any client (or from a script).

Enable adb debugging on your device

To use adb with a device connected over USB, you must enable USB
debugging in the device system settings, under Developer options.

On Android 4.2 and higher, the Developer options screen is hidden by default.
To make it visible, go toSettings > About phone and tap Build number seven
times. Return to the previous screen to find Developer options at the bottom.

On some devices, the Developer options screen might be located or named

differently.
You can now connect your device with USB. You can verify that your device is
connected by executing adb devices from the android_sdk/platform-
tools/ directory. If connected, you'll see the device name listed as a "device."

Note: When you connect a device running Android 4.2.2 or higher, the system
shows a dialog asking whether to accept an RSA key that allows debugging
through this computer. This security mechanism protects user devices because it
ensures that USB debugging and other adb commands cannot be executed
unless you're able to unlock the device and acknowledge the dialog.

Android Runtime

The Android runtime (ART) is the default runtime for devices running Android
5.0 (API level 21) and higher. This runtime offers a number of features that
improve performance and smoothness of the Android platform and apps. You
can find more information about ART's new features in Introducing ART.

However, some techniques that work on Dalvik do not work on ART. This
document lets you know about things to watch for when migrating an existing
app to be compatible with ART. Most apps should just work when running with
ART.

Addressing garbage collection (GC) issues

Under Dalvik, apps frequently find it useful to explicitly call System.gc() to

prompt garbage collection (GC). This should be far less necessary with ART,
particularly if you're invoking garbage collection to prevent GC_FOR_ALLOC-
type occurrences or to reduce fragmentation. You can verify which runtime is in
use by calling System.getProperty("java.vm.version"). If ART is in use, the
property's value is "2.0.0" or higher.

ART has a compacting garbage collector under development on the Android

Open Source Project (AOSP). Once the compacting garbage collector is in use,
objects may be moved in memory. If you use C/C++ code, do not perform
operations that are incompatible with compacting GC

Preventing stack size issues

 Dalvik had separate stacks for native and Java code, with a default Java stack
size of 32KB and a default native stack size of 1MB. ART has a unified stack
for better locality. Ordinarily, the ART Thread stack size should be
approximately the same as for Dalvik. However, if you explicitly set stack sizes,
you may need to revisit those values for apps running in ART.

In Java, review calls to the Thread constructor that specify an explicit stack size.
For example, you will need to increase the size if StackOverflowError occurs.
In C/C++, review use of pthread_attr_setstack() and pthread_attr_setstacksize() for
threads that also run Java code via JNI. Here is an example of the error logged
when an app attempts to call JNI AttachCurrentThread() when the pthread size is
too small:

 F/art: art/runtime/thread.cc:435]

Attempt to attach a thread with a too-small stack (16384 bytes)

Android R.java is an auto-generated file by aapt (Android Asset Packaging

Tool) that contains resource IDs for all the resources of res/ directory.

If you create any component in the activity_main.xml file, id for the

corresponding component is automatically created in this file. This id can be
used in the activity source file to perform any action on the component. It
includes a lot of static nested classes such as menu, id, layout, attr, drawable,
string etc.

Note :If you delete R.Java file android creates it automatically .