Android is a mobile operating system built on a modified Linux kernel and developed under the Android Open Source Project, with Google as the lead maintainer. Among mobile platforms, Android is the dominant one by device count: it runs on smartphones, tablets, watches, televisions and car head units made by hundreds of manufacturers.
Android combines an open-source core with optional proprietary layers. Device makers can ship the open code as is, but most commercial phones license Google Mobile Services, which adds Google Play, Play services and Google apps. This dual nature explains much of Android’s flexibility and its fragmentation.
How the Android architecture is layered
Android is organized as a stack of layers, each exposing a stable interface to the one above it. The layering lets one application binary run on very different hardware, because device-specific code stays below the framework.
| Layer | Contents | Responsibility |
|---|---|---|
| Linux kernel | Drivers, scheduler, memory management, Binder IPC | Hardware access, process isolation, power |
| Hardware abstraction layer | Vendor modules for camera, audio, sensors | Standard interfaces over vendor drivers |
| Android Runtime (ART) | Bytecode execution, garbage collection | Runs app code compiled from Kotlin or Java |
| Native libraries | Media codecs, graphics, SQLite, Bionic libc | Performance-critical system functions |
| Java API framework | Activity manager, package manager, view system | Services that apps call directly |
| System and user apps | Launcher, settings, installed apps | What the user interacts with |
Applications are packaged as APK files, or delivered from Google Play as Android App Bundles that the store splits per device. ART uses ahead-of-time compilation guided by profiles, mixed with a just-in-time compiler, so frequently used code paths run as native machine code.
Since Project Treble, the vendor implementation is separated from the framework by a stable vendor interface. This lets manufacturers update the Android framework without rewriting all of their hardware drivers, which shortened the time needed to ship new versions.
Security and app isolation in Android
Android isolates each application by giving it a unique Linux user ID and its own private storage directory. The kernel enforces this boundary, and SELinux in enforcing mode adds mandatory access control on top of it, so a compromised app cannot read another app’s data.
- Runtime permissions require user consent for sensitive data such as location, camera and contacts.
- Verified boot checks the integrity of each partition at startup.
- File-based encryption protects user data at rest with keys tied to the lock screen.
- Google Play Protect scans installed apps for known malware on devices with Google services.
The main security weakness is not the design but update delivery. Google publishes monthly security bulletins, yet each manufacturer and sometimes each carrier must integrate and ship them, so patch timeliness varies widely between brands and models.
Android compared with iOS
Android and iOS are the two mobile platforms that matter commercially, and they differ mainly in openness, hardware diversity and distribution control. The table compares the aspects that most affect developers and organizations.
| Aspect | Android | iOS |
|---|---|---|
| Source model | Open-source core, proprietary Google layer | Proprietary |
| Hardware makers | Many manufacturers | Apple only |
| Primary languages | Kotlin, Java, C++ | Swift, Objective-C |
| App distribution | Google Play, other stores, sideloading | App Store, alternative stores in some regions |
| OS update reach | Fragmented, depends on manufacturer | Fast and broad across supported devices |
| Customization | Launchers, default apps, deep system changes | More restricted |
For cross-platform projects, a mobile SDK or framework abstracts many of these differences, but platform-specific behavior around background work, notifications and permissions still has to be handled separately on each side.
Versions, API levels and fragmentation
Every Android release corresponds to an API level, an integer that identifies the framework interfaces available on a device. Developers declare a minSdkVersion that sets the oldest supported release and a targetSdkVersion that tells the system which behavior changes the app has been tested against.
| Setting | Meaning | Practical effect |
|---|---|---|
minSdkVersion | Lowest API level the app installs on | Determines the reachable device base |
targetSdkVersion | API level whose behavior the app opts into | Enables newer privacy and background rules |
compileSdkVersion | API level used to compile the code | Gives access to newer APIs at build time |
Google Play requires new apps and updates to target a recent API level, typically within about one year of the latest release. This pushes the ecosystem toward current security behavior even when older devices remain in use. Fragmentation remains real: a single app may run on screen sizes, chipsets and OS versions spanning many years.
Practical choices and common pitfalls on Android
Teams building for Android succeed when they plan for device diversity from the start rather than treating it as a late testing problem. The decision table below covers frequent situations.
| Situation | Recommended choice | Reason |
|---|---|---|
| New interface code | Jetpack Compose | Current toolkit with active development |
| Background sync | WorkManager with constraints | Respects Doze and battery limits |
| Wide device support | Test on low-memory and older devices | Most failures appear outside flagships |
| Enterprise deployment | Android Enterprise work profile | Separates work and personal data |
Common mistakes include assuming Google services exist on every device, ignoring manufacturer-specific battery savers that kill background work, and hard-coding layouts for one screen density. Each of these produces bugs that appear only on part of the installed base.
Put simply
Android is the software that makes most phones work. It decides how apps start, how they share the screen and how they use the battery, the camera and the internet. Many different companies build phones that run Android, which is why Android phones come in so many shapes and prices.
Think of Android as a shared engine that different car makers put into their own cars. The engine is the same, but each maker adds its own body and dashboard, and each decides how often to bring the car in for updates.
In practice
A regional bank builds its mobile banking app for Android and sets minSdkVersion to cover devices from roughly the last seven years, which reaches almost all of its customers. The team uses Kotlin and Jetpack Compose, and stores credentials in the hardware-backed Android Keystore.
In testing, the app worked on the team’s own phones but notifications for incoming payments were delayed on several budget models. The cause was aggressive manufacturer battery optimization that stopped background work. By switching to high-priority push messages for transaction alerts and documenting battery settings for users, the bank brought notification delivery back within seconds on the affected devices.