Android Icon Sizes
Master the right Android icon specifications and avoid common mistakes with this comprehensive guide.

You're probably here because you need the right Android icon specs now, not after digging through old Stack Overflow threads, half-updated design kits, and launcher docs that don't agree with each other.

That confusion is normal. Android icon sizes aren't one number. You're dealing with adaptive icons, density buckets, Play Store artwork, system UI icons, and export rules that can break your visuals if you treat everything like a single PNG. A launcher icon that looks clean in Figma can still get cropped on-device, blur in a legacy context, or fail to match what users see in Google Play.

The fix is to treat icon work as a small asset pipeline, not a one-off design task. You need the canvas size, the safe area, the density output, the file format, and the implementation path to line up. If one part is wrong, the icon usually ships looking slightly off instead of obviously broken, which is worse because teams miss it until after release.

Table of Contents

• Your Single Source of Truth for Android Icons
• Android Icon Sizes Quick Reference Chart
  • Android Icon Specifications Cheat Sheet 2026
• Adaptive Launcher Icons Explained
  • What adaptive icons changed
  • The critical safe zone
• Legacy Launcher Icons and Density Buckets
  • The density model in plain English
  • When legacy assets still matter
• System UI and In-App Icon Sizes
  • Use dp-based sizes for product UI
  • Size the icon and the touch target separately
  • Keep the style system tight
  • Export and test for the actual UI context
• Google Play Store Asset Requirements
  • The one file Google Play actually wants
  • What teams get wrong on the store asset
• Design Workflow and Export Best Practices
  • Start with a master file that matches Android behavior
  • Export for implementation, not for Dribbble
  • Test at small sizes before you call it done
• Common Android Icon Mistakes to Avoid
  • Mistakes that cause clipping and blur
  • Mistakes that hurt recognition
• Frequently Asked Questions About Icon Sizes
  • Do I still need separate legacy launcher sizes
  • What size should I design system icons at
  • Can I use the same artwork for the launcher icon and Play Store icon
  • How do I preview mask issues before release
  • Should I put text inside the app icon

Your Single Source of Truth for Android Icons

If a team asks, “What are the Android icon sizes?” the honest answer is, “Which icon?”

That's the problem. Most articles dump a few pixel tables and stop there. They don't tell you why adaptive icons need breathing room, why a Play Store icon isn't the same deliverable as a launcher icon, or why a perfectly centered mark can still look wrong once Android applies its own mask.

A usable reference has to answer three things at once:

• What size the asset is
• Where the visible area really is
• How that asset gets exported and shipped

That's how production teams avoid rework.

Practical rule: If design, Android implementation, and store submission are handled as separate tasks, icon bugs slip through. Treat them as one pipeline.

This guide does that. It covers the current launcher logic, the older density system you still need to understand, the UI sizes that affect in-app polish, and the final Google Play upload requirements. It also covers the part most spec sheets skip, which is recognition at small sizes. An icon doesn't succeed because it looks impressive at full resolution. It succeeds because users can identify it instantly when it's tiny and surrounded by competitors.

Bookmark this page and use it as your handoff document. It's written for people shipping real apps, not for people collecting design trivia.

Android Icon Sizes Quick Reference Chart

If you only need the numbers, use this table first. Then read the sections below before exporting anything important.

Android Icon Specifications Cheat Sheet 2026

A few numbers matter more than the rest. The Play Store upload asset is fixed. Launcher behavior is adaptive. In-app icons should be designed in dp, not guessed in pixels.

For the launcher and store icon, don't optimize only for the large mockup. Optimize for readability once the icon is reduced and displayed among many others.

Adaptive Launcher Icons Explained

A launcher icon can look perfectly balanced in Figma and still ship cropped on real devices. That usually happens when the file was designed as a finished square instead of an adaptive icon with room for masking and motion.

!A diagram explaining the two-layer approach for creating Android adaptive launcher icons with a system-applied squircle mask.

What adaptive icons changed

Adaptive icons are not one flat image. Android renders them from two layers, then the launcher applies its own mask and visual treatment. Different devices can show the same asset as a circle, squircle, rounded square, or another shape, so the design has to survive outside your mockup.

Use two layers:

• Foreground layer for the logo, symbol, or primary artwork
• Background layer for a solid color, gradient, or simple supporting shape

The working size developers and designers should remember is 108 × 108 dp for the full icon canvas. Treat that outer area as available space for motion, parallax, and masking. Do not treat all of it as guaranteed visible area.

That distinction is what trips teams up. The icon file is square. The icon the user sees is not.

After you understand the layer model, it helps to see the motion and masking behavior in context.

The critical safe zone

The safe zone is the part of the icon that must carry the brand on every launcher. Keep the important artwork in the center and leave the outer edges available for masking and motion. If the logo touches corners or relies on a tight outer shape, some launchers will crop it or make it feel cramped.

A simple rule works well in production: design the foreground so the core symbol still reads when the outer perimeter disappears. That is the difference between an icon that stays legible everywhere and one that only looks right in the source file.

As noted in Icons8's explanation of Android icon sizing and adaptive masks, masked icons can lose visible area around the corners. The practical response is straightforward. Center the brand mark, avoid corner-dependent details, and test the icon against multiple mask shapes before export.

Your canvas is larger than the reliably visible area. Design for the part users will still see after masking.

In review, these patterns usually hold up best:

• Centered symbols with clear silhouettes stay readable across masks
• Backgrounds without important edge detail crop cleanly
• Bold shapes and moderate stroke weight survive downscaling better than thin outlines
• Text-heavy icons break first and should be avoided

For teams shipping assets, the primary check is not whether the icon looks polished at full artboard size. Check whether the symbol remains obvious at launcher size, inside different masks, on both light and dark wallpapers.

Legacy Launcher Icons and Density Buckets

Adaptive icons are the current standard, but legacy launcher assets still explain how Android thinks about scaling. If you don't understand density buckets, a lot of asset decisions feel arbitrary when they're not.

!A chart illustrating the specific pixel dimensions for legacy Android launcher icons across various density buckets.

The density model in plain English

Android uses canonical launcher icon sizes of 48 × 48 px (mdpi), 72 × 72 px (hdpi), 96 × 96 px (xhdpi), 144 × 144 px (xxhdpi), and 192 × 192 px (xxxhdpi), mapped to 160/240/320/480/640 dpi respectively. Material also standardizes 24dp for common icons, with 20dp, 40dp, and 48dp used in denser or larger UI contexts, according to the Android density chart from Icon Handbook.

Those numbers matter because Android doesn't assume one physical pixel means one visual unit across devices. The same icon has to stay visually consistent on screens with very different pixel densities. Density buckets are Android's answer to that problem.

If you've ever seen an icon look soft on one device and sharp on another, it usually means the app relied on scaling instead of providing the right asset or a clean vector source.

When legacy assets still matter

In production work, legacy sizes still matter in a few situations:

• Backward compatibility: Older devices and older launcher contexts may still depend on traditional raster outputs.
• Fallback handling: If a vector or adaptive implementation doesn't behave the way you expect, prebuilt raster assets can save time.
• Asset QA: Exporting the standard buckets is still a useful way to inspect whether the icon survives scaling cleanly.

A practical workflow is to think of legacy icons as support assets, not the primary design target. The primary design target is the adaptive icon system. The density outputs are how you keep that system looking clean across the long tail of Android hardware and launcher behavior.

System UI and In-App Icon Sizes

A common production mistake shows up after launch. The app icon looks polished on the home screen, but the toolbar, tabs, and action icons inside the product feel mismatched, blurry, or oversized on real devices.

That usually happens because teams treat interface icons like mini branding assets. Android UI icons are layout components. Size them in dp, align them to the grid, and test them in the contexts where users tap them.

Use dp-based sizes for product UI

For most Android interfaces, 24 dp × 24 dp is the default size for common action icons. Use 20 dp only when the layout is particularly dense and readability still holds up. Use 40 dp or 48 dp for larger visual treatments, such as prominent empty states, oversized action areas, or surfaces where the icon is part of a bigger touch target.

Start with these rules:

• 24 dp for app bars, standard actions, navigation items, and common controls
• 20 dp for compact UI where a 24 dp icon creates crowding
• 40 dp or 48 dp for larger supporting graphics or high-emphasis interface moments

The trade-off is simple. Smaller icons create space, but they lose recognition faster. Larger icons read better, but they can make the interface feel heavy and reduce information density.

Size the icon and the touch target separately

Teams often confuse icon size with tap area. They are not the same thing.

A 24 dp icon can sit inside a much larger touch target. That is the right setup for many buttons, because the glyph stays visually balanced while the interactive area remains comfortable. If the icon itself is enlarged just to make tapping easier, the UI usually starts to look clumsy before usability improves.

This matters most in top bars, bottom navigation, and list rows, where spacing errors compound quickly across the screen.

Keep the style system tight

In-app icons need to read instantly. Decorative detail that works in a launcher icon often fails at interface scale.

Check these points during design review and QA:

• Silhouette clarity: The shape should read at a glance on a real device, not just in Figma at 400 percent zoom.
• Stroke consistency: Keep stroke weight and corner treatment consistent within the same icon set.
• Optical balance: Icons with the same bounding box can still look different in size. Adjust visually, not only mathematically.
• Spacing discipline: Leave enough internal padding so icons do not feel cramped beside text, chips, or toggles.

If a settings, search, or share icon needs a second look, the problem is usually scale, stroke, or spacing.

Export and test for the actual UI context

A clean asset pipeline helps more than another round of visual tweaking. Keep a vector master, export the sizes your product uses, and verify them against light theme, dark theme, disabled state, and tinted state. Also test on low and high density devices, because an icon that looks balanced in a design file can still render poorly once Android scales and rasterizes it in context.

If you are preparing product visuals beyond the installed app itself, this guide to creating app store screenshots that convert pairs well with icon QA and helps keep your presentation assets consistent with the shipped interface.

Google Play Store Asset Requirements

The Play Store icon is a separate deliverable. Treating it as an afterthought is how teams end up with listing artwork that feels off-brand or gets awkwardly masked.

The one file Google Play actually wants

Google Play requires a 512 × 512 px final icon in 32-bit PNG format, using sRGB color space, with a maximum file size of 1024 KB, according to the official Google Play app icon specifications.

That file is the high-resolution master for your Play Store listing. It is not just a nice-to-have export. It's the public-facing icon users see before they ever install the app.

A few operational rules follow from that:

• Export square artwork
• Use PNG
• Keep the color profile in sRGB
• Don't exceed the file-size cap
• Match the installed-app brand closely

If you're also preparing your broader store listing visuals, this guide to creating app store screenshots that convert is a useful companion to the icon work.

What teams get wrong on the store asset

The most common mistake is baking presentation effects into the artwork. Don't pre-round the corners. Don't rely on edge details that sit too close to the boundary. Don't assume the square export is the same thing users will visually experience after Google applies its treatment.

Another mistake is over-detailing the Play Store icon because the source file is large. Yes, the file is high resolution. No, that doesn't mean more detail is better. The icon still needs to read instantly when reduced in listings and search results.

The store asset should feel like the same brand as the launcher icon, but designed with platform masking and thumbnail recognition in mind.

Design Workflow and Export Best Practices

Most icon problems aren't design problems. They're handoff problems. The concept is fine, then someone exports the wrong bounds, merges the wrong layers, or ships a raster that looked crisp only at one size.

!A five-step infographic detailing the professional workflow for designing and exporting Android application icons for different screens.

Start with a master file that matches Android behavior

Build the source artwork in Figma, Sketch, or Adobe Illustrator as vectors first. Even if you eventually export PNGs, the master should stay editable and scalable. For adaptive launcher work, keep the foreground and background on separate layers from the beginning. If you merge them too early, someone later has to rebuild the icon just to support the proper Android structure.

A clean file setup usually includes:

1. One master artboard for the full adaptive canvas
2. A visible safe area guide
3. A separate foreground group
4. A separate background group
5. A store icon artboard for the Google Play upload

That sounds basic, but it prevents the usual asset chaos.

Export for implementation, not for Dribbble

The export package should reflect how Android Studio expects assets, not how a design portfolio likes to display them. Name things plainly. Keep foreground and background exports distinct. If engineering is using Android Studio's Image Asset Studio, feed it a clean source instead of a flattened marketing graphic.

For handoff, use a checklist:

• Foreground asset: Keep the brand mark isolated.
• Background asset: Use a simple fill or controlled background treatment.
• Legacy exports: Generate the raster outputs your project still needs.
• Play Store file: Export the dedicated store master separately.
• Naming: Keep names aligned with implementation conventions so nobody guesses later.

If your team also needs a press-ready asset pack for launch, partnerships, or media requests, keep that separate from the Android implementation package. This guide to making a press kit is useful for that workflow.

Test at small sizes before you call it done

Many teams often under-test their icons. Recent guidance still warns against text, thin lines, and busy textures, and stresses that the subject needs to remain recognizable at around 24dp, which is why micro-size recognition is now one of the most useful filters in icon review, as discussed in MobileAction's app icon guide.

That advice matches what happens in acquisition and store browsing. Users rarely study your icon in isolation. They see it as a thumbnail, in clutter, at speed.

Use a practical review pass:

• Shrink the icon early: If the core symbol disappears, simplify it.
• Check line weight: Thin strokes often collapse first.
• Remove text: Letters nearly always become noise at small scale.
• Test on busy backgrounds: Some icons only look clean on a white canvas.
• Compare beside competitors: Recognition is relative, not absolute.

The best app icon often isn't the most detailed one. It's the one users can identify fastest when it's tiny.

Common Android Icon Mistakes to Avoid

Icon bugs usually come from reasonable decisions made in the wrong context. A designer optimizes for the large canvas. A developer reuses the launcher asset somewhere it doesn't belong. A marketer exports the store icon as if it were just another social image.

!A visual guide comparing common Android icon mistakes with correct design approaches for better app interface quality.

Mistakes that cause clipping and blur

Some failures are purely technical.

• Ignoring the safe area: The artwork looks centered in the design file but gets clipped after masking.
• Exporting only one raster size: Android scales it where needed, and the result looks soft.
• Flattening adaptive layers: You lose the system behavior that the launcher expects.
• Using mismatched padding: One icon sits too large, another too small, and the app feels sloppy even if each file is technically valid.

These aren't subtle in the final product. Users may not describe the issue precisely, but they notice the app feels less polished.

Mistakes that hurt recognition

Other mistakes are visual, not technical.

• Too much detail: Tiny highlights, textures, or interior shapes compete with the core symbol.
• Text inside the icon: Words shrink into illegible noise.
• Weak silhouette: The icon needs color and detail to be understood, which means it fails when reduced.
• Overdesigned backgrounds: The background starts fighting the subject instead of supporting it.

A good icon survives reduction because the main form stays obvious. A bad one needs explanation.

Here's the review standard I use with teams:

If the icon only works when zoomed in, it isn't finished.

Frequently Asked Questions About Icon Sizes

Do I still need separate legacy launcher sizes

If your app supports contexts where legacy assets still matter, yes. Adaptive icons are the modern standard, but legacy outputs are still useful for compatibility, fallbacks, and QA. Teams that skip them entirely often discover issues only after testing on a wider device mix.

What size should I design system icons at

Use dp as your source of truth for interface icons. Standard Android UI icon work usually starts at 24 dp, with 20 dp, 40 dp, and 48 dp used when the UI context demands a smaller or larger presentation, as covered earlier.

Can I use the same artwork for the launcher icon and Play Store icon

You should keep them brand-consistent, but don't think of them as the same file with a different export button. The launcher icon lives inside Android's adaptive system. The Play Store icon is a high-resolution listing asset with its own presentation context. The design can match closely while still being prepared separately.

How do I preview mask issues before release

Use Android Studio and test on actual devices with different launcher styles if you can. The key thing to inspect is whether important visual elements remain intact after masking. If the icon only looks right in one mask shape, the design is too fragile.

Should I put text inside the app icon

Usually no. Text becomes hard to read fast, especially when the icon appears at micro-size beside many competitors. Symbols, initials used very sparingly, or a strong abstract mark usually hold up better than words.

For Android icon sizes, the right question usually isn't “Can this fit?” It's “Will this still be recognizable after scaling, masking, and crowding?”

If you're building a mobile app and your acquisition costs are high because the creative isn't doing its job, Marketing For Apps By @designerants is worth a look. They focus specifically on mobile app ads, with strong copywriting and creative built to generate desire, not just impressions.