Android App Security · Components & Intents · Lesson 1 of 5

The Four Building Blocks

Meet activities, services, receivers and providers, the parts every app is built from.

Screens and shared data

You saw in Mobile Fundamentals that every APK has a manifest. Part of its job is to list the app's components: the building blocks Android can start on the app's behalf. There are four kinds, and each has its own tag in the manifest.

• An activity (<activity>) is one screen you can interact with, like an inbox or a compose window.
• A service (<service>) does work without a screen, like syncing or playing music.
• A broadcast receiver (<receiver>) wakes up to react to an announcement, like "the phone just finished starting up".
• A content provider (<provider>) manages a set of data, like contacts or notes, and can hand it to other apps in a controlled way.

Here's something that surprises people. An Android app has no single front door. On a computer, a program usually starts at one spot in its code. On Android, the system can start any declared component directly. Tapping the app icon starts one activity. Sharing a photo into the app might start a different one. A component that isn't declared in the manifest is invisible to the system and never runs (broadcast receivers are the one exception, since apps can also register them in code while running).

Activities, services and receivers are started with an intent, a message to the system that says what should happen. Content providers work differently. Another app doesn't send them an intent. It asks a helper called a ContentResolver to query or change the data, and the system passes the request to the provider.

Every one of these components is a possible way in, which is why security reviewers read this part of the manifest first.

On the simulated phone, tap the component lines in the QuickNotes manifest and note what kind each one is and whether it's marked exported.

Work you can't see

Services and broadcast receivers do their jobs off screen, so it helps to know how Android keeps them in check.

A service is for work that should continue even when you leave the app. Android limits how much apps can do in the background, because hidden work drains battery and can hide misbehavior. So when an app needs to keep running where you'd notice it, like a navigation app giving directions or a music player, it uses a foreground service. A foreground service must show a notification while it runs. That's a deliberate design choice: if an app is busy in the background, you get to see it.

Recent versions tightened this further. Since Android 13 you can usually swipe that notification away, and a list in the pulled-down notification shade (the Task Manager) shows apps with active foreground services and lets you stop them. Apps that target Android 14 or later must also declare a foreground service type, such as mediaPlayback or location, which says what the service is for.

A broadcast receiver listens for broadcasts, messages that the system or other apps send out to anyone interested. Examples include "boot completed", "battery low" and "airplane mode changed". The QuickNotes manifest asks for RECEIVE_BOOT_COMPLETED, which lets a receiver start each time the phone turns on.

Receivers used to be a favorite trick for apps that wanted to wake up constantly. Since Android 8.0, apps can no longer use the manifest to sign up for most general broadcasts, though a short list of exceptions like boot completed still works.

As a phone owner, the takeaway is simple. An app can run code when you never opened it, through a receiver or a service. Foreground services announce themselves with a notification, so an unexpected one from an app you don't recognize is worth a closer look.