Android: what it is, system architecture and Kotlin development

What is Android?

Android is a mobile operating system based on the Linux kernel, developed by Google since 2007. The source code is open under the Apache 2.0 license as part of the Android Open Source Project (AOSP). Each manufacturer can modify the system and install it on their devices.

According to StatCounter (2026), Android holds about 72% of the global mobile OS market. The largest manufacturers are Samsung, Xiaomi, Oppo, Vivo, Google Pixel. Fragmentation is a key platform issue: thousands of models with different OS versions are in use simultaneously.

Android's architecture is built on the permissions principle: each app runs under a separate Linux UID and has access only to its own data. Access to system resources (camera, microphone, contacts) is requested via Android Permissions at runtime, starting from Android 6 (API 23).

Android Version History

Android 1.0 was released in 2008 on the HTC Dream. Key milestones: Android 4.0 Ice Cream Sandwich (unified UI for phones and tablets), Android 5.0 Lollipop (Material Design), Android 6.0 (runtime permissions), Android 10 (dark theme, gestures), Android 12 (Material You). Since 2023, Google has switched to annual major releases without dessert names.

Android Architecture: Four Key Layers

The Android architecture consists of four main layers that isolate hardware from user applications. Each layer uses the services of the layer below through strictly defined interfaces.

Linux Kernel and HAL

The bottom layer is a modified Linux kernel (LTS, version 6.x in Android 15). It handles memory management, processes, network stack and drivers. The Hardware Abstraction Layer (HAL) provides a unified API for interfacing with hardware: camera, Bluetooth, Wi-Fi, sensors. Manufacturers implement HAL modules without affecting the upper layers.

Android Runtime (ART)

ART executes app DEX bytecode. Starting from Android 5.0, ART replaced Dalvik and uses Ahead-of-Time (AOT) compilation for improved performance. Each app has its own process with a separate ART instance. Garbage collection (GC) runs with minimal pauses — a typical GC pause is 2–4 ms.

Application Framework

The Framework is the layer the developer works with directly. It includes Activity Manager (screen stack), Content Providers (data access), Resource Manager (localization, resources), Notification Manager, Location Manager. All system services are called via Binder IPC — Android's inter-process communication mechanism.

// Example of working with Binder via AIDL interface
interface IDataService : android.os.IInterface {
    fun getData(): List<DataItem>
    fun saveData(item: DataItem): Boolean
}

// Service implementation
class DataService : Service() {
    private val binder = object : IDataService.Stub() {
        override fun getData(): List<DataItem> = repository.getAll()
        override fun saveData(item: DataItem): Boolean = repository.save(item)
    }

    override fun onBind(intent: Intent?): IBinder = binder
}

System Apps

The top layer consists of standard system apps: Phone, Contacts, Camera, Settings, Browser. They have no higher privileges than user apps but can be replaced by third-party apps. In Android 15, system apps are updated via Google Play System Updates independently of manufacturer OTA updates.

Kotlin — The Primary Android Development Language

Kotlin is a statically typed programming language from JetBrains that runs on the JVM. Google announced Kotlin as an official Android language in 2017 at Google I/O. Kotlin is fully compatible with Java but eliminates its shortcomings: null-safety, data classes, extension functions and coroutines.

Null Safety and Types

The main feature of Kotlin is built-in protection against NullPointerException. Types are divided into nullable (String?) and non-null (String). The compiler checks nullable access at build time. Safe call (?.) and Elvis operator (?:) simplify working with optional values without nested checks.

// Example of Kotlin code with coroutines and Flow
data class User(
    val id: Long,
    val name: String,
    val email: String
)

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Long): Result<User> {
        return try {
            val cached = dao.getUser(id)
            if (cached != null) {
                return Result.success(cached)
            }
            val remote = api.fetchUser(id)
            dao.insertUser(remote)
            Result.success(remote)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }

    fun observeUsers(): Flow<List<User>> {
        return dao.observeAll()
            .map { list -> list.sortedBy { it.name } }
            .flowOn(Dispatchers.Default)
    }
}

The example demonstrates coroutines (suspend function) for async network and database access, Flow for reactive observation of data changes, and Result for safe error handling. Coroutines replace callbacks and RxJava without thread overhead.

Kotlin Coroutines and Flow

Kotlin coroutines are lightweight threads running on a shared thread pool. Dispatchers.IO for network and disk, Dispatchers.Main for UI, Dispatchers.Default for CPU-intensive tasks. viewModelScope and lifecycleScope automatically cancel coroutines when the component is destroyed.

// ViewModel with coroutines and StateFlow
class UserViewModel(
    private val repository: UserRepository
) : ViewModel() {

    private val _users = MutableStateFlow<List<User>>(emptyList())
    val users: StateFlow<List<User>> = _users.asStateFlow()

    private val _loading = MutableStateFlow(false)
    val loading: StateFlow<Boolean> = _loading.asStateFlow()

    init {
        viewModelScope.launch {
            repository.observeUsers().collect { userList ->
                _users.value = userList
            }
        }
    }

    fun refresh() {
        viewModelScope.launch {
            _loading.value = true
            repository.getUser(42).onSuccess { user ->
                _users.value = listOf(user)
            }
            _loading.value = false
        }
    }
}

Android Studio and Development Tools

Android Studio is the official IDE based on IntelliJ IDEA, developed by Google. It includes a code editor, Layout Inspector, device emulator, APK Analyzer, Profiler (CPU, Memory, Network, Energy) and Firebase integration. Android Studio 2024 (Ladybug) supports Kotlin 2.0 with multiplatform KMP mode.

Android Emulator

The Android Emulator uses KVM (Linux) or Hyper-V (Windows) for hardware acceleration. It supports simulation of GPS, sensors, camera, calls and SMS. Google Pixel 9 Pro is the recommended configuration for testing with API 35 and 8 GB emulator RAM.

Android Profiler and Debugging

The Profiler displays CPU load, memory allocation, network requests and power consumption in real time. Memory Profiler allows heap dumping and leak analysis via reference tree. Network Inspector records all HTTP/HTTPS requests with body and headers. Android Studio Canary is used for in-depth analysis.

Android App Components

An Android app consists of four types of components, each with its own entry point and lifecycle. Components are registered in the AndroidManifest.xml file.

Activity and Intent

Activity is the basic user interface component. Each screen is a separate Activity or Fragment within an Activity. Navigation between screens is done via Intent — an object containing an action (ACTION_VIEW, ACTION_SEND) and data (URI). In Jetpack Navigation Graph, navigation is described in XML.

Service and WorkManager

Service performs background tasks, but since Android 8, background services are restricted. WorkManager is the recommended library for deferred and guaranteed background tasks with support for chains, constraints (e.g., only while charging) and restart after crash.

Jetpack Compose vs XML Layouts

The choice between Jetpack Compose and traditional XML layouts is the main architectural decision when starting an Android project. XML Layouts (RecyclerView, ConstraintLayout, FrameLayout) have been the standard since 2008. Jetpack Compose was introduced in 2021 as a declarative alternative.

Google recommends Jetpack Compose for all new projects. XML Layouts remain relevant for legacy project support and cases where maximum View customization (Canvas, SurfaceView) is needed. Compose code is on average 40% shorter than equivalent XML + ViewBinding.

// Jetpack Compose — user profile screen
@Composable
fun ProfileScreen(
    user: User,
    onEditClick: () -> Unit,
    modifier: Modifier = Modifier
) {
    Column(
        modifier = modifier
            .fillMaxSize()
            .padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        AsyncImage(
            model = user.avatarUrl,
            contentDescription = "User avatar",
            modifier = Modifier
                .size(120.dp)
                .clip(CircleShape)
        )

        Spacer(modifier = Modifier.height(16.dp))

        Text(
            text = user.name,
            style = MaterialTheme.typography.headlineMedium
        )

        Text(
            text = user.email,
            style = MaterialTheme.typography.bodyLarge,
            color = MaterialTheme.colorScheme.onSurfaceVariant
        )

        Spacer(modifier = Modifier.height(24.dp))

        Button(onClick = onEditClick) {
            Icon(Icons.Default.Edit, contentDescription = null)
            Spacer(modifier = Modifier.width(8.dp))
            Text("Edit profile")
        }
    }
}

@Preview(showBackground = true, showSystemUi = true)
@Composable
fun ProfileScreenPreview() {
    MaterialTheme {
        ProfileScreen(
            user = User(1, "Anna Petrova", "anna@example.com"),
            onEditClick = {}
        )
    }
}

The ProfileScreen function is declared as @Composable — it describes UI declaratively without creating View instances. Compose automatically updates the screen when user changes. @Preview shows the result directly in the IDE without building and running on the emulator.

Activity and Fragment Lifecycle

Each Activity in Android goes through six lifecycle states: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment adds onAttach, onCreateView, onViewCreated. Understanding the lifecycle is critical for memory management and preventing leaks.

Main Activity States

onCreate — called once when the Activity is created. Initialization is performed here: setContentView, adapter setup, LiveData subscription. onResume — Activity is in the foreground and interacting with the user. onPause — Activity loses focus (dialog, another Activity). onStop — Activity is not visible. onDestroy — Activity is destroyed.

// Activity with lifecycle handling via LifecycleScope
class MainActivity : ComponentActivity() {
    private val viewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MaterialTheme {
                lifecycleScope.launch {
                    repeatOnLifecycle(Lifecycle.State.STARTED) {
                        viewModel.users.collect { users ->
                            updateUi(users)
                        }
                    }
                }
            }
        }
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("last_search", searchQuery)
    }

    override fun onRestoreInstanceState(savedInstanceState: Bundle) {
        super.onRestoreInstanceState(savedInstanceState)
        searchQuery = savedInstanceState.getString("last_search", "")
    }
}

Using repeatOnLifecycle ensures that data collection pauses when the Activity goes into the background and resumes when it returns to the foreground. This prevents leaks and unnecessary network requests. onSaveInstanceState saves temporary state on screen rotation.

Google Play: Publishing and Requirements

Google Play is the official Android app store. Developer account registration costs $25 one-time. Each app undergoes automatic Google Play Integrity checks for malicious code, policy violations and incorrect permission usage.

Publishing Requirements

Google requires app signing via Android App Bundle (AAB) or APK. AAB is the recommended format, enabling optimized APK generation for each device configuration. The app must be signed with a key (keystore) with a valid certificate. Google Play App Signing is optional key encryption on Google's side.

Privacy Policy

All apps requesting access to personal data must provide a Privacy Policy. Since 2024, Google requires a Data Safety declaration — a form specifying types of collected data and processing purposes. Apps targeting Android 14+ must use the Declarations API for declaring permissions.