Android Adaptive Icons: Launcher, Round & Monochrome Icon Guide

Android icon resource checklist

Why one Android icon file is not enough

A modern Android app can display its icon in the launcher, Settings, the recent-apps screen, the Play Store, notifications, widgets, and themed-icon surfaces. Those contexts do not all use the same rendering rules. A bitmap that looks correct in one launcher may be cropped, padded, or visually too small in another.

Adaptive icons separate the artwork into layers so Android 8 and newer launchers can apply circular, rounded-square, squircle, teardrop, or vendor-specific masks. Older Android versions still need precomposed legacy assets, so a complete implementation supports both systems instead of treating adaptive icons as a replacement for every PNG.

• Prepare legacy density resources for Android 7 and earlier
• Prepare foreground and background layers for Android 8 and newer
• Add a monochrome layer for Android 13 themed icons
• Keep a separate high-resolution store asset for Google Play and other marketplaces

Design the three layers before exporting

An adaptive icon starts with three conceptual layers. The background should cover the complete canvas with a solid color or a simple full-bleed shape. The foreground should contain only the brand symbol and must not be pre-cropped into a circle or rounded rectangle. The monochrome layer should be a clean one-color silhouette that still reads when Android applies its theme color.

The most common design mistake is placing the logo too close to the edge because the source artboard looks square. Android launchers crop adaptive icons through a safe area and may add their own visual treatment. Keep the meaningful mark comfortably inside the safe zone, remove fragile micro-details, and test the icon at launcher size before finalizing it.

• Background: full-bleed color or restrained background artwork
• Foreground: brand mark only, with transparent space around it
• Monochrome: a simple one-color outline or silhouette
• Safe area: keep text and important geometry away from the crop boundary
• Do not bake the launcher mask into the foreground or background layers

Add the adaptive icon XML

Place adaptive icon definitions in mipmap-anydpi-v26 so Android 8 and newer can load them. The round variant can point to the same layers when the artwork works across masks, or use a dedicated composition when the round launcher needs different spacing. The monochrome reference is used by newer Android versions when themed icons are enabled.

A minimal adaptive icon definition looks like this:

• Create mipmap-anydpi-v26/ic_launcher.xml
• Create mipmap-anydpi-v26/ic_launcher_round.xml
• Reference drawable/ic_launcher_background, drawable/ic_launcher_foreground, and drawable/ic_launcher_monochrome
• Keep the resource names identical across product flavors if the icons are shared

Use a complete manifest configuration

The application manifest should declare both android:icon and android:roundIcon. Android uses the normal icon resource as the default launcher reference, while some launchers and legacy behaviors use roundIcon when it is available. Leaving roundIcon out can produce inconsistent results even when the main adaptive icon is correct.

For an app targeting Android 36 with a minSdk of 24, the manifest should point to stable resource names that exist in both the v26 adaptive configuration and the legacy density folders. This lets resource selection choose the appropriate implementation for the device version.

• Set android:icon="@mipmap/ic_launcher"
• Set android:roundIcon="@mipmap/ic_launcher_round"
• Keep the resource names stable across debug and release builds
• Verify that resource merging has not silently supplied an icon from another module

Do not forget Android 7 legacy resources

Adaptive icon XML is version-qualified with v26, but a project supporting Android 7 still needs fallback resources. Add final-shaped PNGs to mipmap-mdpi, mipmap-hdpi, mipmap-xhdpi, mipmap-xxhdpi, and mipmap-xxxhdpi. Include both ic_launcher.png and ic_launcher_round.png when the manifest references both names.

Legacy PNGs are different from adaptive layers. They should already represent the final icon appearance for the target context, including the shape treatment that older launchers cannot apply dynamically.

• Generate every density instead of relying on one oversized bitmap
• Use the same visual safe area as the adaptive source
• Check both normal and round legacy assets on Android 7 devices
• Avoid allowing an unrelated library module to provide same-named resources

Handle Android 13 themed icons with a monochrome layer

Android 13 and newer can display themed icons when the user enables the setting and the launcher supports it. The monochrome layer is not a miniature version of the colorful launcher icon. It is a deliberate single-color representation that Android can tint to match the wallpaper and system theme.

Use a bold silhouette or outline with enough open space to remain recognizable after tinting. Gradients, tiny text, subtle shadows, and multiple colors do not survive this mode well. Treat the monochrome asset as a separate design deliverable, not as an automatic grayscale conversion.

• Use one foreground color and transparent negative space
• Remove decorative detail that disappears at small sizes
• Test both light and dark wallpaper surfaces
• Check themed mode with the icon enabled and disabled

Decide whether product flavors share icons

If the google and china flavors use the same brand identity, keep the icon resources in the shared app/src/main/res tree. That avoids drift and ensures every variant receives the same adaptive, monochrome, and legacy resources.

If the flavors have different branding, put equivalent resource names in app/src/google/res and app/src/china/res. The build can then select different artwork while the manifest remains unchanged. Test both variants because resource overlays can hide missing files until a particular flavor is assembled.

• Same icon: use shared app/src/main/res resources
• Different icons: use flavor-specific res overlays with identical names
• Build every flavor in CI or before release
• Inspect the merged resources to confirm the intended icon was selected

Keep store icons and notification icons separate

The Google Play listing icon and the launcher adaptive icon serve different purposes. Prepare an independent high-resolution store source and follow each marketplace's upload rules instead of exporting a screenshot from a device launcher. Google Play commonly expects a 512 by 512 square PNG and applies its own presentation treatment.

Notification icons are a separate resource family again. A notification small icon should be a simple white silhouette on a transparent background. Do not reuse a colorful launcher icon in notification code: Android may render it as a solid block or make it unreadable against the notification background.

• Launcher icon: adaptive layers plus legacy fallbacks
• Store icon: independent high-resolution square artwork
• Notification small icon: white-only transparent silhouette
• Do not use a colorful mipmap launcher asset as a notification icon

Test masks, launchers, and real device sizes

A build succeeding does not prove that an adaptive icon is visually correct. Test on at least Android 7, Android 8 or newer, and Android 13 or newer. Use a Pixel and Samsung launcher, then add Xiaomi, Huawei, OPPO, or vivo devices when those markets matter to the app.

The acceptance question is not whether the source SVG looks attractive at 1024 pixels. It is whether the symbol remains centered, recognizable, and properly weighted after a launcher applies its mask and after the user switches between light, dark, and themed surfaces.

• Android 7: legacy normal and round assets
• Android 8+: circular, rounded-square, squircle, and vendor masks
• Android 13+: themed icon on light and dark wallpapers
• Pixel and Samsung at minimum; Xiaomi, Huawei, OPPO, and vivo when relevant
• Check for clipping, excessive padding, transparent edges, and unreadable text