Build Dark Theme Support Into Your Android App

Dark theme went from novelty to expectation the moment Android 10 shipped a system-wide toggle. Users flip that switch and expect every app to follow, and the ones that stay blinding white feel broken. The funny thing is, dark UIs aren't new to Android at all — the platform's default look before Lollipop was dark. We just spent a decade in light-theme land in between. This is our working guide to adding proper dark theme support with Material Design Components, based on the pattern we use on client projects, plus the mistakes we've already made so you can skip them.

Why bother supporting dark theme

Three reasons, in the order we'd rank them. First, users asked for it — loudly enough that Google made it a headline Android 10 feature. Second, comfort: a dark surface emits far less light, which your users' eyes appreciate at 11 pm. Third, battery: on OLED screens, dark pixels draw measurably less power, and most mid-range and flagship phones ship with OLED panels now. Google's own testing showed a large gap in screen power draw between white and dark UIs at high brightness. None of these reasons is exotic. That's the point — dark theme is basic hygiene for a modern Android app, not a premium extra.

Step 1: Inherit from a DayNight theme

Material Design Components does the heavy lifting if you let it. In themes.xml, make your app theme extend a DayNight parent. With Material 3 that looks like this:

<style name="Theme.MyApp" parent="Theme.Material3.DayNight.NoActionBar">

That single parent change gives every Material component in your app — buttons, cards, dialogs, text fields — a light and a dark variant that switches with the system setting. If you're still on the older Material Components library (M2), the equivalent parent is Theme.MaterialComponents.DayNight. The previous version of this article mangled that class name badly; the ones above are correct and copy-pasteable.

Step 2: Kill your hardcoded colours

This is where the real work hides. Every android:textColor='#000000' and every white background baked into a layout will ignore your theme and betray you in dark mode. Replace raw hex values with theme attributes: ?attr/colorSurface for backgrounds, ?attr/colorOnSurface for text and icons, ?attr/colorPrimary for brand accents. The compiler won't catch violations, so grep your layout files for hex values and work through the hits. On one project we inherited, that search returned over four hundred hardcoded colours. Budget real time for this step. It's tedious, and it's most of the job.

Step 3: Provide night-specific resources where needed

Theme attributes cover the components, but you'll still have custom drawables, illustrations and the odd colour that needs a hand-tuned dark version. Android's resource system handles this with the -night qualifier: put alternatives in res/values-night/ and res/drawable-night/, and the system picks them automatically whenever dark theme is active. One rule we enforce on every project: never use pure black. Material's dark baseline is a very dark grey (#121212 in the M2 spec) because pure black makes elevation shadows invisible and produces harsh, smeary contrast on OLED panels while scrolling.

Step 4: Give users an in-app switch

Devices below Android 10 have no system toggle, and even on new phones plenty of people want the app to differ from the system. AppCompatDelegate.setDefaultNightMode() covers all of it with four useful modes: MODE_NIGHT_FOLLOW_SYSTEM (the right default on Android 10 and up), MODE_NIGHT_YES, MODE_NIGHT_NO, and MODE_NIGHT_AUTO_BATTERY, which flips the app dark when battery saver kicks in — the sensible default on older OS versions. Persist the user's choice in DataStore or SharedPreferences and reapply it at launch. It's about twenty lines of Kotlin, all told.

If you're on Jetpack Compose

Compose makes the whole exercise more direct. isSystemInDarkTheme() reads the system state, and your theme composable hands out darkColorScheme() or lightColorScheme() accordingly. On Android 12 and later you can go a step further with dynamicDarkColorScheme(), which pulls Material You colours from the user's wallpaper so your dark theme matches the rest of their device. New projects at our studio do theming this way by default — you can see the broader stack we build with on our technologies page.

Testing: where dark themes go to die

Every dark theme bug we've ever shipped got through because someone tested only the happy screens. Walk every screen, dialog, snackbar, empty state and error state in both modes. Look for dark-on-dark text, invisible dividers, and images with white backgrounds glowing like lightboxes. Check contrast ratios too — WCAG's 4.5:1 minimum for body text applies in dark mode just as much, and low-contrast grey-on-grey is the single most common failure we catch in review. Layout Inspector plus a couple of physical OLED devices rounds out the kit. Half a day of disciplined QA here saves you weeks of drip-fed bug reports later.

If your app predates Android 10 and has hardcoded colours everywhere, retrofitting dark theme is exactly the kind of contained, high-visibility project worth handing to experienced Android and Kotlin developers. It typically lands within a sprint or two, and the budgeting is straightforward — our cost guide explains how we estimate work like this.

Frequently Asked Questions

Does dark theme really save battery?

On OLED and AMOLED screens, yes — dark pixels draw less power, and the saving grows with screen brightness. On LCD panels the backlight stays on regardless, so the saving is negligible. Since most current Android phones use OLED displays, dark theme is a genuine battery win for the majority of your users.

Can I add dark theme without redesigning my app?

Usually, yes. If your app already uses Material components and theme attributes, switching to a DayNight parent theme does most of the work. The effort scales with how many hardcoded colours and custom views you have. A typical retrofit on a mid-size app takes one to two sprints, most of it spent replacing raw hex values and testing every screen in both modes.

What about users on Android 9 and older?

They have no system-wide dark setting, so give them an in-app theme option. AppCompatDelegate.setDefaultNightMode with MODE_NIGHT_AUTO_BATTERY is a good default there — the app goes dark when battery saver turns on — and a manual light/dark choice in your settings screen covers everyone else.

We've been doing this a while: 16 years in software, 250+ apps shipped, ISO 9001:2015 certified, with clients across India, the USA and Australia. Whether you need dark theme retrofitted into a live app or a new Android product built right from the first commit, tell us about it and we'll come back with a concrete plan and an honest estimate.