Jetpack — what it is, architecture components

What is Android Jetpack?

Android Jetpack is a collection of libraries, tools and architectural guidelines from Google, introduced in 2018 at Google I/O. Jetpack replaced the Support Library and Android Architecture Components, merging them into a single ecosystem. Before Jetpack, each Android library was updated independently, creating version conflicts. Jetpack synchronized versions under a single AndroidX identifier and introduced a model of stable major versions with minor patches.

Jetpack libraries are divided into four categories: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Each category addresses tasks of a specific application layer — from data management to the user interface.

Jetpack Philosophy

Google promotes three Jetpack principles: accelerate development (less boilerplate, more business logic), eliminate boilerplate (ViewModel eliminates manual state saving, Room eliminates writing SQLiteOpenHelper) and build with confidence (each library passes 15,000+ tests before release). According to Android Developers (2026), apps using Jetpack have 30% fewer lifecycle-related crashes.

AndroidX as the Foundation

All Jetpack libraries are distributed under the AndroidX identifier (artifacts like androidx.*). AndroidX replaced the Support Library (artifacts like com.android.support.*), splitting the monolithic library into modular artifacts with independent versioning. Migration to AndroidX is done via the android.useAndroidX=true option in gradle.properties — Android Studio automatically converts imports.

Architecture Components: ViewModel, Lifecycle, LiveData

ViewModel — the central component of the Jetpack architecture that stores UI data. Unlike an Activity, which is destroyed on screen rotation, ViewModel remains in memory. A user fills out a form, rotates the phone — the data is not lost. The ViewModel is automatically cleared when the LifecycleOwner (Activity or Fragment) permanently finishes its lifecycle (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Screen launched")
    }
}

LiveData — an observable data container that respects the lifecycle. If the screen is not visible (onStop), LiveData does not send updates — this prevents memory leaks and crashes when trying to update a non-existent Activity. Lifecycle — a class that stores the current state (CREATED, STARTED, RESUMED) and allows other components to subscribe to state changes. Together, ViewModel, LiveData and Lifecycle form the foundation of reactive Android architecture.

ViewModelScope and Coroutines

viewModelScope — a built-in CoroutineScope tied to the ViewModel lifecycle. All coroutines launched in this scope are automatically cancelled when the ViewModel is cleared. This eliminates manual management of Disposable and CompositeDisposable in each ViewModel. Working with viewModelScope requires the androidx.lifecycle:lifecycle-viewmodel-ktx dependency.

Room: working with database on Android

Room is a Jetpack ORM library that provides an abstract layer over SQLite. Instead of writing raw SQL queries and manually converting Cursor to objects, the developer declares an Entity (table), DAO (Data Access Object) and Database (entry point). Room checks SQL queries at compile time via the @Query annotation — if tables or columns do not exist, the build fails with a clear error.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

The User Entity describes a table with three columns. The DAO declares suspend functions for working with coroutines — the query executes on a background thread automatically. Room supports migrations via the @Migration annotation: the developer describes the SQL script for transitioning between versions, and Room executes it without data loss. In the absence of a migration, Room throws an IllegalStateException — this protects projects from accidental data loss when updating the schema.

TypeConverters and Relationships

Room stores only primitive types and their wrappers. For storing lists, Date or custom objects, @TypeConverter is used — a static method that converts a type to String (JSON) or Long (timestamp). Relationships between tables are modeled through nested objects with the @Relation annotation and helper POJO classes with @Transaction for efficient join queries.

Navigation Component: graphs and arguments

Navigation Component — a Jetpack library for managing transitions between screens. Instead of manually calling FragmentTransaction, the developer creates a navigation graph (XML file with destination nodes), and the system generates a Directions class with type-safe transition methods. Navigation Component ensures correct handling of back stack, deep links and argument passing between screens.

// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// In the fragment code:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

The userId arguments are passed in the navigation graph with a type specification (integer) and default value. The ProfileFragmentArgs class is automatically generated by the Navigation Safe Args plugin — it contains all arguments with correct Kotlin types. Deep links are configured in the graph: app:deepLink="app://profile/{userId}". Navigation Component itself parses the URL and creates the back stack as if the user navigated through the interface.

Bottom Navigation and Conditional Navigation

Navigation Component integrates with BottomNavigationView through NavController: each menu item is linked to a destination in the graph. Switching between tabs does not recreate the fragment — Navigation Component preserves state through NavBackStackEntry. For conditional navigation (show login if not authenticated), navController.navigate(condition) is used with a check in onCreate.

AndroidX: the new generation Support Library

AndroidX is a redesigned architecture of the Support Library in which each library received its own artifact with an independent version. Instead of a single com.android.support:appcompat-v7:28.0.0, AndroidX offers androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 and so on. This eliminated the problem where different dependencies pulled different versions of the Support Library, causing conflicts.

Migration to AndroidX is done automatically in Android Studio 3.2+ via the menu Refactor → Migrate to AndroidX. Studio replaces all imports in Java/Kotlin files, manifests and resources. Backward compatibility is the main advantage of AndroidX: libraries work on Android 5.0 (API 21) and above, covering 97% of active devices according to Google Play Console (2025).

Main AndroidX Artifacts

The most frequently used artifacts: appcompat (dark theme, Material Design on old APIs), recyclerview (adaptive lists with ViewHolder), constraintlayout (flexible container with flat hierarchy), cardview (Material Design cards), preference (settings screen with Material style). Each artifact is versioned independently, speeding up the delivery of fixes without updating the entire package.

Other important Jetpack libraries

In addition to Architecture and AndroidX, Jetpack includes many specialized libraries for typical mobile development tasks. WorkManager — for background tasks with guaranteed execution (sync, log upload), supports periodic and delayed tasks, as well as network and battery constraints. DataStore — a replacement for SharedPreferences based on coroutines, supporting typed properties (Preferences DataStore) and Protocol Buffers (Proto DataStore).

• Hilt — a Dagger-based DI framework that simplifies dependency injection through @HiltViewModel, @Inject, @Module annotations. Built-in integration with ViewModel and Navigation.
• Paging 3 — a library for paginated data loading from network/DB with support for RemoteMediator (network + cache), StateFlow and Compose.
• CameraX — an API for working with the camera, abstracting manufacturer differences (Samsung, Xiaomi, Honor) through a unified CameraController interface.
• Security Crypto — data encryption via EncryptedSharedPreferences and EncryptedFile based on AES-256 with a master key in Android Keystore.

Each library has its own minimal SDK and artifact. Google releases major versions once a year (coinciding with the Android release) and security patches quarterly. Recommendation — include only the needed libraries to avoid increasing APK size. The full Jetpack collection (all artifacts) weighs over 20 MB, but a typical app uses 5–7 libraries, adding 3–5 MB to the APK.