Android Framework

Ten years of continuous Android development, from the pre-Jetpack View era through to Compose and platform-level work. This page summarizes the parts of the framework I work with directly and the behaviour I rely on knowing without looking up.

UI and the View system#

The View system remains present in every long-lived codebase, and most Compose migrations are incremental. I work across both.

• Layout with ConstraintLayout, including chains, barriers, guidelines and the flat-hierarchy patterns that replace nested weights.
• XML layouts, styles, themes and resource qualifiers, including the configuration matrix for size, density, locale and night mode.
• Custom views: onMeasure / onLayout / onDraw, touch handling, and Canvas-level drawing where the widget set does not fit.
• RecyclerView internals — view types, stable ids, DiffUtil, prefetch and recycled view pools — as the usual source of list jank.

Components and lifecycle#

The lifecycle contract is where framework misunderstanding turns into production defects, so it is worth stating precisely.

Two distinctions matter in practice: the difference between a Fragment's own lifecycle and its viewLifecycleOwner, and the difference between configuration change recreation and process death. ViewModel survives the first; only SavedStateHandle or persisted state survives the second.

Jetpack Compose#

Compose work in production alongside existing View code, rather than as a greenfield rewrite:

• Composition and recomposition behaviour, state hoisting, and stability of parameters.
• Side-effect APIs (LaunchedEffect, DisposableEffect, remember scopes) and the failure patterns they exist to prevent.
• Interoperability in both directions — ComposeView inside XML hierarchies and AndroidView inside Compose — which is what makes incremental migration viable.
• Navigation, theming and design-system components shared across screens.

Navigation and task behaviour#

Navigation defects are usually task-level rather than screen-level. The relevant surface is the back stack, launch modes and task affinity, deep link handling, Up versus Back semantics, and the way a task is restored after the process is killed in the background.

Execution and background work#

// Deferred, constraint-driven work belongs to WorkManager;
// immediate user-visible work does not.
val request = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(
        Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .build()
    )
    .build()

Foreground and background execution differ sharply, and the boundary has moved with almost every platform release. The working set here is: coroutines and structured concurrency for in-process work, WorkManager for deferrable work, foreground services with the correct service type where the work must be visible, and an accurate model of Doze, App Standby and background start restrictions.

Permissions, intents and IPC#

Notifications#

Channels, importance, grouping, and the styles that platforms treat specially; foreground service notifications; full-screen intents and their restrictions; and the post-Android 13 notification permission flow.

Storage and data#

Scoped storage and the MediaStore access model, the SAF document APIs, app-private storage, Room for structured data, DataStore for preferences, and EncryptedFile / Keystore-backed storage where data is sensitive.

Process and resource lifecycle#

Process priority and the low-memory killer, onTrimMemory behaviour, cold versus warm start paths, and process death in the background — the case that most reliably exposes state that was never persisted.

Performance and debugging#

Framework knowledge exists mostly to support this: reading traces in Perfetto and Systrace, attributing jank to layout, allocation or main-thread I/O, diagnosing ANRs from their traces, and interpreting tombstones for native crashes. See Performance and Debugging for the tooling side.