Demystifying the Android Toolchain: Building Blocks of App Development.

In the world of mobile technology, Android applications have become ubiquitous, enhancing our lives in countless ways. But behind every app's sleek interface lies a complex process powered by the Android toolchain. In this exploration, we'll unveil the essential components of this toolchain, demystifying the process that turns code into the apps we rely on daily. Join us on a journey through the heart of Android app development.

Understanding the Android Toolchain

The Android toolchain is a set of tools and utilities used by developers to compile, build, test, and package Android applications. It transforms your source code into an APK (Android Package) file, which can be installed and run on Android devices. Let's delve into its primary components:

Java Compiler (javac): Java is the primary language for Android app development. The Java compiler converts your Java source code (.java files) into bytecode (.class files).
Dalvik or ART (Android Runtime): Android uses a virtual machine to run applications. Dalvik, the earlier runtime, was succeeded by ART (Android Runtime) in later versions. These runtimes convert bytecode into machine code that is executed by the device's CPU.
Android Package Manager (aapt): This tool helps package your app's resources (like images, layouts, and XML files) into the APK file. It also handles resource localization, density, and other configuration-related tasks.
Android Asset Packaging Tool (aapt2): A more modern version of aapt, aapt2 further improves resource management, making it more efficient and robust.
Dex Compiler (dx): The Dalvik or ART runtime doesn't directly execute Java bytecode. Instead, it converts it into a specialized bytecode format called Dalvik Executable (DEX). The dx tool performs this conversion.
Android Debug Bridge (ADB): ADB is a versatile command-line tool for interacting with Android devices and emulators. It allows you to install, debug, and manage apps on devices.
Gradle and Android Studio: While not part of the Android toolchain per se, Gradle and Android Studio are essential development tools. Gradle is a build automation tool, and Android Studio is the official Integrated Development Environment (IDE) for Android development. These tools simplify the build and development process.

The Build Process

Now that we've introduced the Android toolchain components, let's explore how they work together during the build process:

1. Source Code: You start with your app's source code, typically written in Java or Kotlin. You also have XML files for layouts and resources like images, strings, and themes.
2. Compilation: The Java compiler (javac) translates your Java/Kotlin source code into bytecode (.class files). These files contain your app's logic.
3. Resource Packaging: The Android Asset Packaging Tool (aapt or aapt2) packages your app's resources and assets into a format that can be efficiently used by Android. This includes XML layout files, images, and other resources.
4. Dex Conversion: The Dex Compiler (dx) converts the bytecode (.class files) into Dalvik Executable (DEX) files. These DEX files are optimized for execution on Android devices.
5. APK Assembly: The Android Package Manager (aapt) takes the DEX files, resources, and other necessary assets, and assembles them into an APK file. This file is the heart of your Android application.
6. Signing and Debugging: Before distribution, you may need to sign the APK with a digital certificate. During development, you can use the Android Debug Bridge (ADB) to install and debug your app on emulators or physical devices.
7. Distribution: Once your app is fully tested and ready for release, you can distribute the signed APK via the Google Play Store or other distribution channels.

Conclusion

The Android toolchain is the backbone of Android app development, seamlessly transforming your source code and resources into a functional application. Understanding its components and how they work together is crucial for any Android developer.

As the Android ecosystem evolves, new tools and optimizations are continually introduced, making app development more efficient and user-friendly. Stay updated with the latest developments in the Android toolchain to ensure your apps are at the forefront of innovation in the mobile world. Happy coding!

HB Blog 149: Cross Platform Development.

In computing, cross-platform software (also multi-platform software or platform-independent software) is computer software that is implemented on multiple computing platforms. Cross-platform software may be divided into two types; one requires individual building or compilation for each platform that it supports, and the other one can be directly run on any platform without special preparation. Cross-platform programming is the practice of actively writing software that will work on more than one platform.

There are a number of tools which are available to help facilitate the process of cross-platform programming:

1.     8th: A cross-platform development language, which utilizes Juce as its GUI layer. The platforms it currently supports are: Android, iOS, Windows, macOS, Linux and Raspberry Pi.
2.     Anant Computing: A mobile application platform that works in all Indian languages, including their keyboards, which is also supports AppWallet and Native performance inside all operating systems.
3.     Appcelerator: It helps in building native apps by deploying just a single JavaScript code base. It provides your web content in a native application, ensuring your code is not wrapped around a web container unlike few other such solutions.
4.     AppearIQ: A framework that supports the workflow of app development and deployment in an enterprise environment. Natively developed containers present hardware features of the mobile devices or tablets through an API to HTML5 code thus facilitating the development of mobile apps that run on different platforms.
5.     Cairo: A free software library used to provide a vector graphics-based, device-independent API. It is designed to provide primitives for 2-dimensional drawing across a number of different backends. Cairo is written in C and has bindings for many programming languages.
6.     Cocos2d: An open source toolkit and game engine for developing 2D and simple 3D cross-platform games and applications.
7.     Delphi: A cross platform IDE, which uses Pascal language for Development. Currently it supports Android, iOS, Windows, macOS.
8.     Ecere SDK: A cross platform GUI & 2D/3D graphics toolkit and IDE, written in eC and with support for additional languages such as C and Python. Currently it supports Linux, FreeBSD, Windows, Android, macOS and the Web through Emscripten or Binaryen (WebAssembly)
9.     Eclipse: An open source cross-platform development environment. Implemented in Java with a configurable architecture which supports many tools for software development. Add-ons are available for several languages, including Java and C++.
10.     FLTK: Another open source cross platform toolkit, but more lightweight because it restricts itself to the GUI.
11.     fpGUI: An open source widget toolkit that is completely implemented in Object Pascal. It currently supports Linux, Windows and a bit of Windows CE.
12.     GeneXus: A Windows rapid software development solution for cross-platform application creation and deployment based on knowledge representation and supporting C#, COBOL, Java including Android and BlackBerry smart devices, Objective-C for Apple mobile devices, RPG, Ruby, Visual Basic, and Visual FoxPro.
13.     GLBasic: A BASIC dialoect and compiler that generates C++ code. It includes cross compilers for many platforms and supports numerous platform (Windows, Mac, Linux, Android,iOS and some exotic handhelds).
14.     GTK+: An open source widget toolkit for Unix-like systems with X11 and Microsoft Windows.
15.     Haxe: An open source cross-platform language.
16.     Juce: An application framework written in C++, used to write native software on numerous systems (Microsoft Windows, POSIX, macOS), with no change to the code.
17.     Lazarus: A programming environment for the FreePascal Compiler. It supports the creation of self-standing graphical and console applications and runs on Linux, MacOSX, iOS, Android, WinCE, Windows and WEB.
18.     Max/MSP: A visual programming language that encapsulates platform-independent code with a platform-specific runtime environment into applications for macOS and Windows.
19.     MechDome: A cross-platform Android runtime. It allows unmodified Android apps to run natively on iOS and macOS
20.     MonoCross: An open-source model-view-controller design pattern where the model and controller are shared cross-platform but the view is platform-specific.
21.     Mono: An open-source cross-platform version of Microsoft .NET (a framework for applications and programming languages)
22.     MoSync: An open-source SDK for mobile platform app development in the C++ family
23.     Mozilla application framework: An open source platform for building macOS, Windows and Linux applications
24.     OpenGL: A cross-platform 3D graphics library.
25.     PhoneGap: It enables software programmers to build applications for mobile devices using CSS3, HTML5, and JavaScript instead of relying on platform-specific APIs like those in Android, iOS, or Windows Phone.
26.     PureBasic: A proprietary cross-platform language and IDE for building macOS, Windows and Linux applications
27.     Qt: An application framework and widget toolkit for Unix-like systems with X11, Microsoft Windows, macOS, and other systems—available under both open source and proprietary licenses.
28.     Simple and Fast Multimedia Library: A multimedia C++ API that provides low and high level access to graphics, input, audio, etc.
29.     Simple DirectMedia Layer: An open-source cross-platform multimedia library written in C that creates an abstraction over various platforms’ graphics, sound, and input APIs. It runs on many operating systems including Linux, Windows and macOS and is aimed at games and multimedia applications.
30.     Smartface: A cross platform native app development tool to create mobile applications for Android and iOS, using WYSIWYG design editor with JavaScript code editor.
31.     Tcl/Tk
32.     Ultimate++: A C++ cross-platform rapid application development framework focused on programmers productivity. It includes a set of libraries (GUI, SQL, etc..), and an integrated development environment. It supports Windows and Unix-like OS-s. The U++ competes with popular scripting languages while preserving C/C++ runtime characteristics. It has its own integrated development environment, TheIDE, which features BLITZ-build technology to speedup C++ rebuilds up to 4 times.
33.     Unity: Another cross-platform SDK which uses Unity Engine.
34.     Unreal: A cross-platform SDK which uses Unreal Engine.
35.     V-Play Engine: V-Play is a cross-platform development SDK based on the popular Qt framework. V-Play apps and games are created within Qt Creator.
36.     WaveMaker: A Cross-platform low-code development tool to create responsive web and hybrid mobile (Android & iOS) applications.
37.     WinDev: Integrated Development Environment for Windows, Linux, .Net and Java (also with support for Internet and Intranet)
38.     wxWidgets: An open source widget toolkit that is also an application framework.[14] It runs on Unix-like systems with X11, Microsoft Windows and macOS. It permits applications written to use it to run on all of the systems that it supports, if the application does not use any operating system-specific programming in addition to it.
39.     Xamrin: With a C#-shared codebase, developers can use Xamarin tools to write native Android, iOS, and Windows apps with native user interfaces and share code across multiple platforms, including Windows and macOS. 
40.     Xojo: A RAD IDE developed by Xojo, Inc. that uses an object-oriented programming language to create desktop, web and iOS apps. Xojo makes native, compiled desktop apps for macOS, Windows, Linux and Raspberry Pi. It creates compiled web apps that can be run as standalone servers or through CGI. And it recently added the ability to create native iOS apps.

HB Blog 136: Android Automation Testing Using Espresso Framework.

Android tests are based on JUnit, and you can run them either as local unit tests on the JVM or as instrumented tests on an Android device. This post provides an introduction to the concepts and tools for building Android tests.
When using Android Studio to write any of your tests, your test code must go into one of two different code directories (source sets). For each module in your project, Android Studio includes both source sets, corresponding to the following test types:

Local unit tests:-
Located at module-name/src/test/java/.
These tests run on the local JVM and do not have access to functional Android framework APIs.

Instrumented tests:-
Located at module-name/src/androidTest/java/.
These are all tests that must run on an Android hardware device or an Android emulator.
Instrumented tests are built into an APK that runs on the device alongside your app under test. The system runs your test APK and your app under tests in the same process, so your tests can invoke methods and modify fields in the app, and automate user interaction with your app.
        Building Instrumented Unit Tests: Build complex unit tests with Android dependencies that cannot be satisfied with mock objects.
        Automating User Interface Tests: Create tests to verify that the user interface behaves correctly for user interactions within a single app or for interactions across multiple apps.
        Testing App Component Integrations: Verify the behavior of components that users do not directly interact with, such as a Service or a Content Provider.

However, the local unit tests and instrumented tests described above are just terms that help distinguish the tests that run on your local JVM from the tests that run on the Android platform (on a hardware device or emulator). The real testing types that you should understand when building a complete test suite are described in the following table.

Type	Subtype	Description
Unit tests
	Local Unit Tests	Unit tests that run locally on the Java Virtual Machine (JVM). Use these tests to minimize execution time when your tests have no Android framework dependencies or when you can mock the Android framework dependencies.
	Instrumented unit tests	Unit tests that run on an Android device or emulator. These tests have access to Instrumentation information, such as the Context of the app you are testing. Use these tests when your tests have Android dependencies that mock objects cannot satisfy.
Integration Tests
	Components within your app only	This type of test verifies that the target app behaves as expected when a user performs a specific action or enters a specific input in its activities. For example, it allows you to check that the target app returns the correct UI output in response to user interactions in the app’s activities. UI testing frameworks like Espresso allow you to programmatically simulate user actions and test complex intra-app user interactions.
	Cross-app Components	This type of test verifies the correct behavior of interactions between different user apps or between user apps and system apps. For example, you might want to test that your app behaves correctly when the user performs an action in the Android Settings menu. UI testing frameworks that support cross-app interactions, such as UI Automator, allow you to create tests for such scenarios.

JUnit
You should write your unit or integration test class as a JUnit test class. The framework offers a convenient way to perform common setup, teardown, and assertion operations in your test.
A basic JUnit test class is a Java class that contains one or more test methods. A test method begins with the @Test annotation and contains the code to exercise and verify a single functionality (that is, a logical unit) in the component that you want to test.
The following snippet shows an example JUnit integration test that uses the Espresso APIs to perform a click action on a UI element, then checks to see if an expected string is displayed.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

@RunWith(AndroidJUnit4.class) @LargeTest public class MainActivityInstrumentationTest { @Rule public ActivityTestRule mActivityRule = new ActivityTestRule<>( MainActivity.class); @Test public void sayHello(){ onView(withText("Say hello!")).perform(click()); onView(withId(R.id.textView)).check(matches(withText("Hello, World!"))); } }

In your JUnit 4 test class, you can call out sections in your test code for special processing by using the following annotations:

• @Before: Use this annotation to specify a block of code that contains test setup operations. The test class invokes this code block before each test. You can have multiple @Before methods but the order in which the test class calls these methods is not guaranteed.
• @After: This annotation specifies a block of code that contains test tear-down operations. The test class calls this code block after every test method. You can define multiple @After operations in your test code. Use this annotation to release any resources from memory.
• @Test: Use this annotation to mark a test method. A single test class can contain multiple test methods, each prefixed with this annotation.
• @Rule: Rules allow you to flexibly add or redefine the behavior of each test method in a reusable way. In Android testing, use this annotation together with one of the test rule classes that the Android Testing Support Library provides, such as ActivityTestRule or ServiceTestRule.
• @BeforeClass: Use this annotation to specify static methods for each test class to invoke only once. This testing step is useful for expensive operations such as connecting to a database.
• @AfterClass: Use this annotation to specify static methods for the test class to invoke only after all tests in the class have run. This testing step is useful for releasing any resources allocated in the @BeforeClass block.
• @Test(timeout=): Some annotations support the ability to pass in elements for which you can set values. For example, you can specify a timeout period for the test. If the test starts but does not complete within the given timeout period, it automatically fails. You must specify the timeout period in milliseconds, for example: @Test(timeout=5000).

Use the JUnit Assert class to verify the correctness of an object's state. The assert methods compare values you expect from a test to the actual results and throw an exception if the comparison fails. Assertion classes describes these methods in more detail.

HB Blog 128: Android Jack And Jill Toolchain.

Jack is a new Android toolchain that compiles Java source into Android dex bytecode. It replaces the previous Android toolchain, which consists of multiple tools, such as javac, ProGuard, jarjar, and dx.
For information related to Android Build System visit post HB Blog 51: Android Build System - How Android Apk Is Built.

The Jack toolchain provides the following advantages:

• Completely open source
  Available in AOSP; partners are welcome to contribute. 
• Speeds compilation time
  Jack has specific supports to reduce compilation time: pre-dexing, incremental compilation and a Jack compilation server. 
• Handles shrinking, obfuscation, repackaging and multidex
  Using a separate package such as ProGuard is no longer necessary.

Jack has its own .jack file format, which contains the pre-compiled dex code for the library, allowing for faster compilation (pre-dex).

The Jill tool translates the existing .jar libraries into the new library format, as shown below.

How to use Jack in Android build?
You don’t have to do anything differently to use Jack — just use your standard makefile commands to compile the tree or your project. Jack is the default Android build toolchain for M.
The first time Jack is used, it launches a local Jack compilation server on your computer:

•     This server brings an intrinsic speedup, because it avoids launching a new host JRE JVM, loading Jack code, initializing Jack and warming up the JIT at each compilation. It also provides very good compilation times during small compilations (e.g. in incremental mode).
•     The server is also a short-term solution to control the number of parallel Jack compilations, and so to avoid overloading your computer (memory or disk issue), because it limits the number of parallel compilations.

The Jack server shuts itself down after an idle time without any compilation. It uses two TCP ports on the localhost interface, and so is not available externally. All these parameters (number of parallel compilations, timeout, ports number, etc) can be modified by editing the $HOME/.jack file.

Jack and Jill are available in Build Tools version 21.1.1, and greater, via the SDK Manager. Complementary Gradle and Android Studio support is also already available in the Android 1.0.0+ Gradle plugin.'
Using Gradle, add the following to your module-level build config file:

1 2 3 4 5 6 7 8 9 10 11

android { ... buildToolsVersion '21.1.2' defaultConfig { // Enable the experimental Jack build tools. jackOptions { enabled true } } ... }

Jack limitations:

• The Jack server is mono-user by default, so can be only used by one user on a computer. If it is not the case, please, choose different port numbers for each user and adjust SERVER_NB_COMPILE accordingly. You can also disable the Jack server by setting SERVER=false in your $HOME/.jack.  
•  CTS compilation is slow due to current vm-tests-tf integration. 
•  Bytecode manipulation tools, like JaCoCo, are not supported.