Android Skin Switching: A Practical Guide with Kotlin and Jetpack Compose

Introduction

“Skin switching” — the ability to let users change the app’s color theme at runtime — has evolved from a niche feature into an expectation. A reading app that offers a dark, sepia, and light mode feels more polished. A launcher that adapts its accent color to the user’s wallpaper feels more alive.

In the classic View-based world, runtime skinning was genuinely hard: you had to intercept LayoutInflater, swap Resources instances, and manually refresh every visible view. With Jetpack Compose, theming becomes a first-class, declarative concern. Switching a few state values recomposes the entire UI with the new palette — no view tree walking required.

This article covers:

1. A Compose-first approach using MaterialTheme and dynamic color schemes.
2. Persisting the user’s choice with DataStore.
3. Supporting Material You dynamic color on Android 12+.
4. The classic View-based skinning technique for legacy codebases.
5. Best practices for a maintainable theming layer.

The Big Picture

There are three common strategies for Android skinning:

For greenfield projects, the Compose approach is strongly recommended. It is simpler, more testable, and aligns with Google’s current direction. This article leads with Compose and includes a legacy section for teams still on Views.

Defining Color Schemes

Compose’s MaterialTheme wraps a ColorScheme (light or dark) plus typography and shapes. To support multiple skins, define a set of named palettes and map each to a ColorScheme.

import androidx.compose.ui.graphics.Color

object SkinColors {
    val BluePrimary = Color(0xFF1E88E5)
    val BlueVariant = Color(0xFF6AB7FF)

    val GreenPrimary = Color(0xFF2E7D32)
    val GreenVariant = Color(0xFF81C784)

    val PurplePrimary = Color(0xFF7B1FA2)
    val PurpleVariant = Color(0xFFBA68C8)

    val SepiaBackground = Color(0xFFF4ECD8)
    val SepiaSurface = Color(0xFFEAE0C8)
    val SepiaOnSurface = Color(0xFF5B4636)
}

Define the available skins as a sealed enum so the compiler enforces exhaustive handling:

enum class AppSkin(val displayName: String) {
    Blue("Ocean Blue"),
    Green("Forest Green"),
    Purple("Royal Purple"),
    Sepia("Sepia Paper")
}

Building Color Schemes per Skin

Create a function that returns a ColorScheme for a given skin and dark-mode flag. Using lightColorScheme and darkColorScheme builders keeps the palette Material-compliant.

import androidx.compose.material3.lightColorScheme
import androidx.compose.material3.darkColorScheme
import androidx.compose.material3.ColorScheme

fun buildColorScheme(skin: AppSkin, isDark: Boolean): ColorScheme {
    val (primary, secondary) = when (skin) {
        AppSkin.Blue   -> SkinColors.BluePrimary   to SkinColors.BlueVariant
        AppSkin.Green  -> SkinColors.GreenPrimary  to SkinColors.GreenVariant
        AppSkin.Purple -> SkinColors.PurplePrimary to SkinColors.PurpleVariant
        AppSkin.Sepia  -> SkinColors.SepiaOnSurface to SkinColors.SepiaOnSurface
    }

    return if (isDark) {
        darkColorScheme(
            primary = primary,
            secondary = secondary,
            background = Color(0xFF121212),
            surface = Color(0xFF1E1E1E)
        )
    } else {
        if (skin == AppSkin.Sepia) {
            lightColorScheme(
                primary = primary,
                secondary = secondary,
                background = SkinColors.SepiaBackground,
                surface = SkinColors.SepiaSurface,
                onSurface = SkinColors.SepiaOnSurface
            )
        } else {
            lightColorScheme(
                primary = primary,
                secondary = secondary,
                background = Color(0xFFFFFBFE),
                surface = Color(0xFFFFFBFE)
            )
        }
    }
}

Holding Theme State

Theme choice is app-wide state. Expose it from a ViewModel backed by a StateFlow so any composable can observe it and recompose automatically when the user picks a new skin.

import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.StateFlow
import kotlinx.coroutines.flow.asStateFlow

class ThemeViewModel(
    private val preferences: ThemePreferences
) : ViewModel() {

    private val _skin = MutableStateFlow(AppSkin.Blue)
    val skin: StateFlow<AppSkin> = _skin.asStateFlow()

    private val _dynamicColor = MutableStateFlow(false)
    val dynamicColor: StateFlow<Boolean> = _dynamicColor.asStateFlow()

    init {
        viewModelScope.launch {
            preferences.skinFlow.collect { _skin.value = it }
        }
    }

    fun setSkin(newSkin: AppSkin) {
        viewModelScope.launch {
            preferences.setSkin(newSkin)
        }
    }

    fun setDynamicColor(enabled: Boolean) {
        viewModelScope.launch {
            preferences.setDynamicColor(enabled)
        }
    }
}

Persisting the Choice with DataStore

DataStore (Preferences variant) is the modern replacement for SharedPreferences. It is coroutine-based, type-safe, and avoids blocking the main thread.

import android.content.Context
import androidx.datastore.preferences.core.edit
import androidx.datastore.preferences.core.stringPreferencesKey
import androidx.datastore.preferences.core.booleanPreferencesKey
import androidx.datastore.preferences.preferencesDataStore
import kotlinx.coroutines.flow.map

private val Context.dataStore by preferencesDataStore(name = "theme_prefs")

class ThemePreferences(private val context: Context) {

    private val skinKey = stringPreferencesKey("skin")
    private val dynamicKey = booleanPreferencesKey("dynamic_color")

    val skinFlow = context.dataStore.data.map { prefs ->
        prefs[skinKey]?.let { name ->
            AppSkin.entries.firstOrNull { it.name == name }
        } ?: AppSkin.Blue
    }

    val dynamicFlow = context.dataStore.data.map { prefs ->
        prefs[dynamicKey] ?: false
    }

    suspend fun setSkin(skin: AppSkin) {
        context.dataStore.edit { it[skinKey] = skin.name }
    }

    suspend fun setDynamicColor(enabled: Boolean) {
        context.dataStore.edit { it[dynamicKey] = enabled }
    }
}

Wiring It into the App Theme

The root composable reads the current skin and dark-mode state, builds the matching ColorScheme, and feeds it to MaterialTheme. On Android 12+, optionally use dynamic color to derive the palette from the system wallpaper.

import android.os.Build
import androidx.compose.foundation.isSystemInDarkTheme
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.dynamicDarkColorScheme
import androidx.compose.material3.dynamicLightColorScheme
import androidx.compose.runtime.Composable
import androidx.compose.runtime.collectAsState
import androidx.compose.runtime.getValue
import androidx.compose.ui.platform.LocalContext

@Composable
fun AppTheme(
    themeViewModel: ThemeViewModel,
    content: @Composable () -> Unit
) {
    val skin by themeViewModel.skin.collectAsState()
    val dynamicColor by themeViewModel.dynamicColor.collectAsState()
    val isDark = isSystemInDarkTheme()
    val context = LocalContext.current

    val colorScheme = when {
        dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
            if (isDark) dynamicDarkColorScheme(context)
            else dynamicLightColorScheme(context)
        }
        else -> buildColorScheme(skin, isDark)
    }

    MaterialTheme(
        colorScheme = colorScheme,
        typography = AppTypography,
        shapes = AppShapes,
        content = content
    )
}

Because colorScheme is read inside the composition, changing the skin triggers a recomposition of everything below MaterialTheme. The new palette applies instantly with no manual view invalidation.

The Skin Picker UI

A simple dialog or bottom sheet lets the user choose. Because the selection flows through the ViewModel into DataStore and back via StateFlow, the change is reflected everywhere automatically.

import androidx.compose.foundation.layout.*
import androidx.compose.material3.*
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier

@Composable
fun SkinPickerSheet(
    currentSkin: AppSkin,
    onSkinSelected: (AppSkin) -> Unit,
    onDismiss: () -> Unit
) {
    ModalBottomSheet(onDismissRequest = onDismiss) {
        Column(modifier = Modifier.padding(16.dp)) {
            Text("Choose a theme", style = MaterialTheme.typography.titleMedium)
            Spacer(Modifier.height(12.dp))
            AppSkin.entries.forEach { skin ->
                ListItem(
                    headlineContent = { Text(skin.displayName) },
                    trailingContent = {
                        if (skin == currentSkin) {
                            Icon(Icons.Default.Check, contentDescription = null)
                        }
                    },
                    modifier = Modifier.clickable {
                        onSkinSelected(skin)
                    }
                )
            }
        }
    }
}

Applying the Skin to Custom Components

The power of Compose theming is that any composable reading MaterialTheme.colorScheme adapts automatically. For skins that need custom tokens beyond the Material palette (for example, a brand-specific gradient), expose them through a CompositionLocal.

import androidx.compose.runtime.staticCompositionLocalOf
import androidx.compose.ui.graphics.Brush

data class ExtendedTokens(
    val headerGradient: Brush,
    val cardShadowAlpha: Float
)

val LocalExtendedTokens = staticCompositionLocalOf {
    ExtendedTokens(
        headerGradient = Brush.horizontalGradient(listOf(Color.Gray, Color.DarkGray)),
        cardShadowAlpha = 0.2f
    )
}

fun extendedTokensFor(skin: AppSkin): ExtendedTokens = when (skin) {
    AppSkin.Blue   -> ExtendedTokens(Brush.horizontalGradient(listOf(SkinColors.BluePrimary, SkinColors.BlueVariant)), 0.25f)
    AppSkin.Green  -> ExtendedTokens(Brush.horizontalGradient(listOf(SkinColors.GreenPrimary, SkinColors.GreenVariant)), 0.2f)
    AppSkin.Purple -> ExtendedTokens(Brush.horizontalGradient(listOf(SkinColors.PurplePrimary, SkinColors.PurpleVariant)), 0.3f)
    AppSkin.Sepia  -> ExtendedTokens(Brush.horizontalGradient(listOf(SkinColors.SepiaSurface, SkinColors.SepiaBackground)), 0.15f)
}

Provide them in the theme wrapper:

CompositionLocalProvider(LocalExtendedTokens provides extendedTokensFor(skin)) {
    MaterialTheme(colorScheme = colorScheme, content = content)
}

Components then read LocalExtendedTokens.current.headerGradient and stay in sync with the active skin.

Supporting Dark Mode

Dark mode is orthogonal to skin choice. The isSystemInDarkTheme() composable follows the system setting. To let users override it independently, store a UiMode enum (Light, Dark, System) in DataStore and resolve it:

enum class UiMode { Light, Dark, System }

@Composable
fun resolveDarkMode(mode: UiMode): Boolean = when (mode) {
    UiMode.Light  -> false
    UiMode.Dark   -> true
    UiMode.System -> isSystemInDarkTheme()
}

Pass the result into buildColorScheme instead of calling isSystemInDarkTheme() directly, so a user who forces light mode keeps it even when the system is dark.

The Classic View-Based Approach

For apps still using XML layouts, runtime skinning requires more machinery. The core idea: maintain a SkinResource that points to a different Resources instance (or an overlay asset pack), then walk the view tree and reapply tagged attributes.

Step 1: Tag Views in XML

<TextView
    android:id="@+id/title"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:textColor="@color/skin_text_primary"
    app:skin_enable="true" />

Step 2: Intercept LayoutInflater

Register a LayoutInflater.Factory2 that captures view creation and records the skin-enabled attributes for later refresh:

class SkinLayoutInflaterFactory : LayoutInflater.Factory2 {

    override fun onCreateView(
        parent: View?,
        name: String,
        context: Context,
        attrs: AttributeSet
    ): View? {
        val view = delegate.createView(parent, name, context, attrs)
        if (view != null) {
            SkinAttributeCollector.collect(view, attrs)
        }
        return view
    }
}

Step 3: Reload Resources and Refresh

When the user picks a new skin, build a new Resources instance pointing at the skin’s asset path, update a global SkinResourceManager, and iterate over every collected view to reapply its attributes:

fun applySkin(skinPath: String) {
    val assetManager = AssetManager::class.java.newInstance()
    assetManager.addAssetPath(skinPath)
    val newResources = Resources(
        assetManager,
        Resources.getSystem().displayMetrics,
        Resources.getSystem().configuration
    )
    SkinResourceManager.update(newResources)
    SkinAttributeCollector.refreshAll()
}

This approach is powerful but fragile: it must handle background resources, compound drawables, state lists, and custom views. It also requires re-registering the factory after configuration changes. For this reason, new projects should prefer Compose.

Handling Configuration Changes

When the system dark mode toggles or the device rotates, the activity recreates. Because theme state lives in a ViewModel and is persisted in DataStore, it survives recreation. The StateFlow re-emits the current skin, and the UI rebuilds with the correct palette.

If you use the View-based approach, reapply the skin in Activity.onCreate after super and layout inflation so the recreated views pick up the active resources.

Testing the Theme Layer

Because the color scheme is a pure function of (AppSkin, Boolean), it is trivially unit-testable:

@Test
fun blueSkinInDarkModeUsesDarkBackground() {
    val scheme = buildColorScheme(AppSkin.Blue, isDark = true)
    assertEquals(Color(0xFF121212), scheme.background)
}

@Test
fun sepiaSkinUsesSepiaSurface() {
    val scheme = buildColorScheme(AppSkin.Sepia, isDark = false)
    assertEquals(SkinColors.SepiaSurface, scheme.surface)
}

For the ViewModel, inject a fake ThemePreferences in tests to verify that setSkin propagates through the StateFlow.

Best Practices Checklist

1. Model skins as a sealed enum. Exhaustive when branches prevent missing cases.
2. Keep color schemes pure. A function from (skin, isDark) -> ColorScheme is easy to test and reason about.
3. Persist with DataStore, not SharedPreferences. DataStore is coroutine-friendly and avoids ANRs.
4. Use CompositionLocal for extended tokens. This keeps brand-specific colors out of the Material palette while staying reactive.
5. Offer dynamic color on Android 12+. Users love palettes that match their wallpaper; gate it behind a toggle.
6. Decouple dark mode from skin. Let users force light, dark, or follow-system independently of accent color.
7. Avoid hard-coded colors in composables. Always read from MaterialTheme.colorScheme or a CompositionLocal so skins apply everywhere.
8. Pre-warm the DataStore read. Read the saved skin in the splash screen so the first frame already uses the correct theme, avoiding a flash of the default skin.
9. For legacy View apps, isolate the skin loader. Keep SkinAttributeCollector behind an interface so you can migrate to Compose piece by piece.
10. Test the palette functions. Regression-proof your color logic so a refactor cannot silently swap a skin’s identity.

Conclusion

Skin switching in Android has two faces. The legacy View-based path is a lesson in how hard runtime theming used to be — intercepting layout inflation, swapping Resources, and manually refreshing views. The Compose path is a lesson in how good declarative theming can be: a pure function from skin to ColorScheme, observed via StateFlow, applied by recomposition.

For new work, lean entirely on Compose. Define your skins as an enum, build color schemes with a pure function, persist the choice in DataStore, and expose any extra brand tokens through CompositionLocal. The result is a theming layer that is testable, reactive, and a pleasure to extend when the design team asks for “just one more skin.”