ImageConver · Day 16 · Platform icon guide
Android App Icon Sizes Guide
Choose Android launcher, adaptive, monochrome, and Google Play icon assets by separating installed-app resources from store-listing artwork. The current Android model uses density-aware resources and adaptive layers rather than one permanently rounded bitmap.
Izravan odgovor
What this page produces and where it fits
Choose Android launcher, adaptive, monochrome, and Google Play icon assets by separating installed-app resources from store-listing artwork. The current Android model uses density-aware resources and adaptive layers rather than one permanently rounded bitmap. This guide covers launcher identity and Play listing artwork. It does not replace Android Studio previews, OEM launcher testing, notification-icon guidance, splash-screen artwork, TV assets, wearable assets, or brand review.
Icon work is a delivery system, not a single resize. A platform may use the same identity in a store, launcher, notification, settings screen, browser tab, installed web app, shortcut, or operating-system search result. Each context can apply a different mask, density, cache, compositing rule, or validation step. The recommended icon system should therefore be treated as a tested derivative of an editable brand master.
Begin with clean source artwork. Keep the primary subject centered, remove unnecessary text, avoid hairline details, and judge the design at the smallest real display size. Do not add a platform’s outer rounded mask or system shadow to the source unless current official guidance explicitly requires that treatment. A large preview can hide problems that become obvious at 16, 32, or 48 pixels.
File dimensions alone do not prove correctness. Confirm color space, alpha behavior, file paths, MIME types, manifest or asset-catalog metadata, purpose declarations, naming, cache behavior, and actual device presentation. Preserve the source file and document which generator settings produced the reviewed release assets.
Tijek rada
A controlled four-step icon process
- 1
Pregledajte izvor
Start with a high-resolution editable master and identify installed-app versus store contexts.
- 2
Odaberite postavke
Design adaptive foreground, background, and optional monochrome layers on the required grid.
- 3
Generate assets
Generate legacy density resources only where the supported project needs them.
- 4
Validate delivery
Validate Android Studio output, Play Console requirements, themed icons, and multiple OEM masks.
Visual quality
Fit, detail, transparency, and recognition
Framing and padding
Fit mode changes meaning. Contain keeps the complete source and can add background around it; cover fills the square and can crop edges. Padding is useful for centered marks, but too much creates a small-looking icon. Compare masks and tiny previews before accepting a value.
Small-size detail
Raster downsizing removes detail. Thin strokes, small counters, photographic textures, and type can blur or disappear. The best small icon is often a simplified drawing rather than a mechanically reduced version of marketing artwork. Review the actual pixel output at 100% scale.
Background behavior
Transparency is not neutral. A browser, launcher, store, or operating system may composite transparent pixels against a color you did not choose. Full-bleed platform artwork should use a deliberate background where guidance expects one, while formats such as ICO may intentionally retain alpha.
Color contrast and recognition matter across light, dark, tinted, and themed environments. Test the icon near competing icons and against multiple backgrounds. Automated generation cannot determine whether a mark is distinctive, accessible, legally cleared, or consistent with current brand rules.
Važna ograničenja
What automated icon generation cannot guarantee
- OEM launchers can apply different masks and visual treatments.
- Android platform guidance evolves and project templates may generate resources differently.
- The Play listing icon does not replace installed launcher assets.
- A size table cannot evaluate brand clarity, contrast, accessibility, or small-scale legibility.
Slučajevi upotrebe
Where this page fits in production
Product delivery
Plan resources for a new Android application.
Compatibility work
Modernize a legacy bitmap launcher icon.
Quality review
Separate a Play listing asset from packaged app resources.
Developer handoff
Audit clipping and themed-icon readiness before release.
Implementation
Configuration, caching, and release checks
Keep generated files at stable, cache-aware URLs. A manifest or HTML declaration that points to a missing file is not rescued by having the right PNG on a developer’s computer. Verify HTTP status, content type, dimensions, file bytes, and same-origin or cross-origin behavior where relevant.
Treat configuration files as reviewable code. Inspect every manifest entry, asset-catalog record, folder name, scale factor, purpose token, and filename before merging. A generated fragment intentionally avoids guessing application names, start URLs, bundle identifiers, theme colors, or project settings that belong to the real application.
Cache invalidation deserves a release check. Installed web apps, browsers, launchers, build systems, and stores can retain old icon resources. Use deliberate versioned paths or cache policy, rebuild the application, reinstall when necessary, and distinguish a stale resource from an incorrectly generated resource.
Validate both geometry and workflow. Geometry includes cropping, safe zones, centering, edge treatment, and small-size clarity. Workflow includes correct source control, repeatable settings, platform configuration, build output, deployment, and rollback. A visually attractive file can still fail because the project references a different filename.
Decision framework
Build the icon set from requirements, not habit
Write down the supported operating systems, browser engines, application targets, project tooling, and distribution channels before selecting files. A list copied from an old blog can be internally consistent yet wrong for a current project. Official platform documentation and the project’s own build warnings are the controlling evidence.
Separate master artwork from delivery derivatives. The master remains editable and high resolution; platform files are reproducible outputs. Keep appearance variants and semantic layers distinct when the platform expects them. Do not ask a resize operation to invent foreground, background, monochrome, dark, or tinted design intent.
Use the table as a starting inventory, then remove assets the project genuinely does not consume and add only requirements supported by official documentation or validated target behavior. Every retained asset needs an owner, source, generation method, configuration reference, and test surface.
Run a release audit after integration. Confirm each generated file is present in the built package or deployed location, referenced by the correct metadata, served with the expected MIME type, and visible after a clean installation. Capture screenshots or build evidence for the supported target matrix.
Recheck guidance when platform tooling changes. Icon pipelines are unusually sensitive to new masks, appearance systems, asset-catalog formats, installation criteria, and store validation. Record the review date and do not present historical dimensions as timeless requirements.
| Asset | Working specification | Validation |
|---|---|---|
| Adaptive layers | 108×108dp foreground and background; essential logo within centered 66×66dp | Android Studio mask previews and real launchers |
| Legacy launcher | 48dp mapped across mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi | Density resource selection |
| Google Play | 512×512, 32-bit PNG, sRGB, full square | Play Console validation |
| Themed icon | Dedicated monochrome layer | Supported Android versions and launchers |
Production checklist
Document the asset inventory and test matrix
Create an inventory before implementation. For each asset, record its platform context, logical purpose, pixel or point dimensions, scale factor, filename, source-art revision, background and alpha policy, configuration reference, and the application or browser that consumes it. This prevents two files with similar dimensions from being treated as interchangeable when their semantics differ.
Define a representative test matrix rather than checking only the developer’s primary device. Include the minimum and maximum supported operating-system versions, relevant density classes, at least one light and dark environment, required appearance or theme variants, and the installation or distribution channel. For web applications, include a clean browser profile and a reinstall after cache changes. For native applications, include a release-style build rather than only an editor preview.
Review small contexts independently. Open exported pixels at 100% scale, place them beside typical neighboring icons, and check silhouette, contrast, edge clarity, and recognition without relying on the app name. Record defects against the editable master so the next iteration changes the design source rather than painting corrections into generated derivatives.
Keep generation reproducible. Save the approved master, generator version or script, settings, official references, review date, and validation evidence together. Checksums can identify the exact files reviewed. If a platform rejects or transforms an asset, preserve the rejection message and resulting presentation because that evidence is more useful than guessing from a generic size list.
Plan maintenance ownership. Someone must recheck platform documentation, build warnings, installation behavior, and store validation when supported targets or tooling change. Retire obsolete files only after proving they are no longer referenced by source code, manifests, asset catalogs, deployment templates, cached application data, or release automation.
Privatnost
Local processing and asset handling
The browser reads the selected source with local file APIs, draws derivatives to canvas, encodes PNG data, and assembles the requested ZIP or ICO in memory. ImageConver does not send source pixels to an icon conversion endpoint in this workflow.
Local processing reduces transfer exposure but does not make a shared device private. Browser downloads, recent-file lists, synchronized folders, backups, extensions, and operating-system previews may retain copies. Use an approved workstation for unreleased brands or confidential product artwork.
Generated object URLs are temporary and are revoked when replaced or reset. Move reviewed assets into controlled project storage, retain the editable master, and close the tab after handling sensitive materials.
Uobičajena pitanja
Android App Icon Sizes Guide FAQ
What is the adaptive icon canvas?
Android guidance uses 108×108dp foreground and background layers, with essential logo content kept within the centered 66×66dp safe region.
What are the legacy density sizes?
A common 48dp launcher icon maps to 48, 72, 96, 144, and 192 pixels for mdpi through xxxhdpi.
What size is the Google Play icon?
Google Play specifies a 512×512 32-bit PNG in sRGB with a maximum file size of 1024KB.
Do I add rounded corners and shadows?
Do not add the outer Play mask or platform shadow. Google Play and launchers apply presentation treatments.
What is a monochrome icon?
It is an optional single-color layer used for themed icon presentation on supported Android versions and launchers.
Are adaptive icons only PNG files?
No. Adaptive icons are defined from foreground and background drawables, which may be vector or bitmap resources.
How should I verify the pack?
Use Android Studio tools, inspect generated resources, install test builds, and review multiple densities, masks, themes, and launchers.
Primarne reference
Current platform documentation
- Android Developers: Adaptive icons
- Android Studio: Create app icons
- Google Play icon design specifications
- Android Developers: Density buckets and units
Last reviewed: October 20, 2026. Platform requirements and tooling change; verify release-critical assets against current primary documentation.