Android Software Internals Quick Reference: A Field Manual and Security Reference Guide to Java-based Android Components

By James Stevenson

Use this handy field guide as a quick reference book and cheat sheet for all of the techniques you use or reference day to day. Covering up to Android 11, this Android Java programming reference guide focuses on non-UI elements with a security focus. You won’t see Android UI development, nor will you see low-level C or kernel techniques. Instead, this book focuses on easily digestible, useful, and interesting techniques in Java and the Android system. 

This reference guide was created out of the need for myself to jot down all the useful techniques I commonly reached for, and so I’m now sharing these techniques with you, whether you are an Android internals software engineer or security researcher. 

What You Will Learn

• Discover the differences between and how to access application names, package names, IDs, and unique identifiers in Android
• Quickly reference common techniques such as storage, the activity lifecycle, and permissions
• Debug using the Android shell
• Work with Android's obfuscation and encryption capabilities
• Extract and decompile Android applications
• Carry out Android reflection and dex class loading

Who This Book Is For

Programmers, developers, and admins with at least prior Android and Java experience.

• Language: English
• Publisher: Apress
• Release date: Mar 10, 2021
• ISBN: 9781484269145

Book preview

© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2021

J. StevensonAndroid Software Internals Quick Referencehttps://doi.org/10.1007/978-1-4842-6914-5_1

1. Introduction

James Stevenson¹  

(1)

London, UK

In 2016 there were more than five million Android developers worldwide. Three years later, in 2019, there were 2.5 billion Android devices in circulation across the world. There is no doubt that Android is a massively adopted operating system, and not going anywhere anytime soon.

This book has been designed for Android software engineers new and old, with a focus away from typical UI design. This book instead focuses on the parts of Java and the Android system that typically go forgotten when learning to build applications. This book will serve as a reference guide for techniques from device and user unique identifiers to ProGuard obfuscation to long-running services - in turn digging into some of the principles not intrinsically obvious from the get-go.

As the name may suggest, this book won’t be covering Android UI development, nor will it be covering low-level C, or Kernel techniques. Instead, this book will be focusing on easily digestible, useful, and interesting techniques in Java and the Android system.

What Is This Book

An Android Java programming reference guide for non-UI elements.

This book covers the Android operating system from Android 4.4 to 11.0.

What This Book Is Not

This book doesn’t include an introduction tutorial for Java; if you’re looking for this, there are many other great resources out there.

This book doesn’t cover any low-level C programming, Kernel interaction, or vulnerability research.

While one or two aspects of the Android UI may be covered in this book, it will not be a key focus.

© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2021

J. StevensonAndroid Software Internals Quick Referencehttps://doi.org/10.1007/978-1-4842-6914-5_2

2. Android Versions

James Stevenson¹  

(1)

London, UK

Android 1.0 was released on September 23, 2008; since then the operating system has gone through countless changes. Table 2-1 denotes the different versions of Android (starting from version 1.5 Cupcake).

The API level in Android defines the supported API functionality on that device. If using a device’s shell prompt (e.g., via the command adb shell, which is available as part of the Android platform tools), you can return the system property that relates to the current API level by running getprop | grep sdk. This can also be done via adb (Android Debug Bridge) from a connected machine.

The following shows an example output of this command as run on a Google Pixel 4a running Android 11:

[ro.build.version.min_supported_target_sdk]: [23]

[ro.build.version.preview_sdk]: [0]

[ro.build.version.preview_sdk_fingerprint]: [REL]

[ro.build.version.sdk]: [30]

[ro.product.build.version.sdk]: [30]

[ro.qti.sdk.sensors.gestures]: [false]

[ro.system.build.version.sdk]: [30]

[ro.system_ext.build.version.sdk]: [30]

[ro.vendor.build.version.sdk]: [30]

Table 2-1

Android Release Versions

© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2021

J. StevensonAndroid Software Internals Quick Referencehttps://doi.org/10.1007/978-1-4842-6914-5_3

3. Fundamentals

James Stevenson¹  

(1)

London, UK

Android Sandbox

Android runs under a multiuser Linux system which means that each application, and its storage, runs under a separate user. This means that under normal circumstances, applications cannot read another application’s data or internal storage. Each process uses its own virtual machine (VM) which segregates applications. Prior to API level 21 (Android 5), this would have been a Dalvik Virtual Machine, and in later versions will instead use the Android Runtime (ART). Both operate in similar fashions, where they simulate a device’s CPUs, registers, and other features while running an application’s compiled Dalvik bytecode. ART, however, is considered to have many performance improvements.

In these VMs applications only have access to the components that they require to run (a policy of least privilege). These individual process VMs are created by Zygote¹ (zai·gowt). Zygote is launched by the Android runtime at startup, with root permissions, with the first virtual machine and all shared Java classes and resources. When a new application wants to launch, a new Zygote process is forked and the application is bound to the thread of the new process, and its code is run inside of it, nonrequired and nonrequested permissions are dropped by Zygote so that the application only possesses the necessary permissions.

Application Components

Activities

Activities are the main entry points for Android applications. Akin to a single web page, an activity is a single screen which in general will only remain running while in the foreground. While not all activities have to be visible, most standard application activities will be. An activity can be programmatically implemented by extending the Activity class .

Services

In general terms services are a utility in Android for providing functionality in the background while an application is not currently running in the foreground, for example, a music player, an email client polling for emails, or a maps application. The preferred technology used for tasking services has changed in Android over the years from using Services to using JobSchedulers. These will be discussed more in Chapter 10.

Broadcast Receivers

Another entry point to the application is where the system, other applications, and the application itself can broadcast events that the application then receives. Broadcast receivers have restricted functionality (where, as a general rule, they can only run for 10 seconds before being considered as unresponsive²) and, because of this, will normally start another form of long-running service such as a foreground Activity or a JobScheduler. A broadcast receiver is implemented by extending the BroadcastReceiver class. These will be discussed more in Chapter 4.

Content Providers

Content providers are used to manage sets of application data so that they are sharable with other applications on a device. Using a URI other applications can query or modify the data even if the application the URI belongs to is not currently running. Examples include images, text files, SQLite databases, etc.

Manifest

An application’s manifest file³ is created precompilation and cannot be edited during runtime. These xml-like files, called AndroidManifest.xml, detail all of the components in a single application (activities, broadcast receivers, services, etc.). The manifest file also details permissions that the application requires, the minimum API level, as well as