Skip to main content

Command Palette

Search for a command to run...

Android Fundamentals: App Components

Updated
5 min readView as Markdown
Android Fundamentals: App Components
R
The best part of knowledge is when you share it.

Introduction

Hi, it's been a while. I know I promised I'd focus on projects instead of theory, but I promise to not be extensive and just give a small introduction to key components in Android apps.

Android Applications

To build apps for Android systems, you need the tools in the Android SDK (Software Development Kit) that compile your source code to the .apk (Android Package) or .aab (Android App Bundle) formats. Android apps are written mainly in Java, Kotlin and C++.

The main difference between an .apk and an .aab is that the first one contains all resources needed by the Android application at runtime, while the second one has the contents of an Android project, including metadata. .apk files are used by the Android system to install apps, while the .aab is a publishing format, from which an .apk can be generated for the specific device requesting installation — from Google Play, for example.

Android is a multi-user system, where each application runs as a different user in a sandbox, with each application isolated from the others. Of course there are means to allow communication between apps, but this must be explicitly declared. Each app runs in its own process, but it's also possible to make apps share the same process, but, again, this must be declared explicitly.

App Components

An Android app can be built upon four main components: Activities, Services, Broadcast Receivers, and Content Providers.

Each component serves its own purpose, and they all can be an entry point for Android apps. Apps can expose their own components for others to use.

Activity

This component represents a single screen that the user directly interacts with when opening the app. An app can have multiple activities forming a cohesive flow. For example, a banking app might first bring you to the login screen, then the balance screen and then the transfer screen, etc, where each screen can be specified by an Activity.

This is the most common component in Android apps; you can do a lot with only this component.

Service

This component is more suitable for background long-term tasks like file downloading, audio playback, data sync, etc. Services can be started by other apps' components, an activity, for example, and they do not provide a user interface. There are two types of services: Started and Bound.

Started Services run in the background until they finish their task. The user may or may not be aware of the service execution, and this impacts how the Android system manages memory. Audio playback is an example of a service that the user notices, so only in really necessary cases the Android system would kill it to reclaim memory, while background data sync the user would not even notice.

Bound Services expose an API for inter-process communication. When an app binds to a service, the Android system prioritizes it at the same level as the app the user is interacting with.

Broadcast Receiver

This component allows your app to respond to events outside user interactions, even when not running. Imagine you want your app to perform an action when the device is turned on, when the battery is low, etc.

They are commonly used as a gateway for other components; they are intended to do as little work as possible. Apps can also send events through Intents to trigger other apps' Broadcast Receivers.

Content Provider

This component allows other apps to access another app's private data, following the rules the app states. For example, an app that allows you to choose a profile picture from your gallery can access the pictures from the gallery app's content provider.

Content Providers are often mistaken for database abstractions, but they are actually a URI-based interface for sharing data across apps. This data can be from a database, internal storage, files, network, etc.

Intents

Android apps cannot interact directly because the Android system architecture isolates them. This is where Intents come into play.

Intents act like messengers between the components, and are delivered by the system to their targets.

Intents can be explicit (specify a component) or implicit (specify a type of component). For example, a note-taking app can use an explicit intent to open the screen to show a specific note's content, and an implicit intent when you click the share button to allow you to choose which app you'd like to use to share your notes.

Final Words

In this article, we gave a brief introduction to Android app components. I also wanted to introduce Jetpack Compose here, but this is more suitable for the next article (spoiler: It's a project).

Thanks for your attention, see you in the next article.

References

Application fundamentals

Introduction to Activities

Services Overview

Broadcasts Overview

Content Providers

Intents And Intent Filters

EOF