Preparing Android assets: mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi

Android asset preparation: where graphics break in release

The most common failure in release is one master from the design stretched by the system for a specific screen. A developer puts an image into a single folder, and on a large flagship or tablet the icon arrives blurry: the system interpolates the raster upward.

The opposite situation is when a file has been added to the project for every density bucket, and the app build weight has grown several times over without a single new screen.

Android selects a resource by density bucket — from mdpi to xxxhdpi — and on a miss it takes the nearest one and scales it. This is where discrepancies between the design and what the user sees come from: shifted margins, cropped edges, different stroke thickness.

The adaptive Android icon adds its own layer of problems: the foreground and background layers sit separately, and a logo outside the safe zone is cropped by the launcher mask on some devices.

Weight and sharpness are solved by one rule — exactly how the asset gets into the project.

Vector for icons, interface elements, and simple shapes; raster formats with variable quality for photos and complex textures; and density buckets generated from a single master file rather than drawn by hand for each screen. Then graphics are sharp everywhere, and the build does not drag five copies of one file.

We break down how Android asset preparation is handled: what checks we put on designs before layout, how we set up generation from a master file, and where we look when the design diverges from the real screen.

What a managed asset set gives a mobile app

Screen densities are multiples of the base: mdpi, hdpi, xhdpi, xxhdpi, and xxxhdpi — steps of 1×, 1.5×, 2×, 3×, and 4×.

Graphics are assembled once by these coefficients, so on any device an icon, illustration, and background land in their own slot without system-side interpolation — the image stays sharp, and proportions and margins do not fall apart.

A common source of truth for palette, corner radii, and line thickness keeps a unified interface style; the same scaling logic is described by Material Design.

The difference shows up in build artifacts. A raster icon laid out across five directories weighs exactly five times as much as one copy — this weight goes into the weight of apk and aab, and along with it grows release build time and the size of the update the user downloads.

Separately, we calculate install failure rate: the larger the package, the more often download is interrupted on a weak connection.

App graphics optimization starts with abandoning raster where there are no photos and gradients: vector icons, stretchable backgrounds for different content, a modern compression format for photographic materials.

We check image compression without quality loss by comparing with a reference on control screens, not "by eye", and only after that fix the coefficient in build rules.

Design edits require one edit of the source rather than synchronously updating five copies: the design changes faster, the release builds more predictably, and visual verification comes down to a few reference resolutions.

Ways of working with graphics: options and limitations

On Android, a resource is selected for screen density: the system itself takes the appropriate copy, and the sharpness of the icon on a high-density screen and build weight on others depend on which variants we put in.

The error is immediately visible to the user — blurry buttons or an app that grows faster than its functionality.

There is no universal method: photos exist only in raster, icons are more profitable to keep as vector, mass elements are cheaper to slice automatically. Below are the options that are actually chosen between.

In practice, approaches are combined: vector for the interface, raster for content, automation for mass sets. We set a default rule for the project and check the result on a screen matrix so that sharpness and weight do not diverge from design expectations.

Implementation stages: from inventory to handoff to the team

Before slicing graphics, we gather the full picture: where the sources are, who updates them, which screens already diverge by density. The order of steps is fixed — a skipped inventory turns into an incomplete scheme and blurry images on some devices at the very first update.

1. Graphic asset audit. We compare the designs with what actually lies in the project: we find duplicates, stretched raster copies, icons drawn for a single density, and images in a common directory without breakdown.
2. Resource slicing scheme. We define a set of density directories (from mdpi to xxxhdpi), naming rules, and what is delivered as vector vs raster — vector handles scaling and removes extra copies.
3. Resource build setup. We connect automatic generation of sets from master files: a new icon no longer appears manually in five directories and is not lost during branch merges.
4. Weight optimization. We recompress rasters, remove unused files, and make sure the delivery size does not grow with every design iteration.
5. Device testing. We run key screens on devices with different density and diagonal: we look at cropping, blur, scaling artifacts, and build installation time.
6. Documentation handoff. We give the team an asset map, naming rules, build configuration, and a regulation for adding new graphics — updating stops being a manual operation.

Graphic sets, slicing rules, and handoff regulations

A ready-made graphics kit is not a folder with pictures but a structure that a third-party team deploys without back-and-forth and clarifications. We hand it over together with the rules: what is where, what each file is called, and what to do when the design is updated. Below is the list of artifacts the client receives.

• Resource directory structure: sets are laid out by density — from mdpi to xxxhdpi, with general and thematic groups separate. New graphics go into their own branch instead of spreading across the project root.
• File naming rules: Latin only, lowercase, screen prefix and density/state suffix — normal, pressed, disabled. The file name itself explains its purpose, without opening the design.
• Asset map: a table "UI element → file → where it is used." With it, any element is found in a minute, not by searching the entire directory.
• Vector and stretchable elements: we deliver icons and backgrounds in editable form; raster copies remain only where texture is needed. This removes rebuilding for new resolutions.
• Graphics update regulation: who initiates rebuilding, which densities are rebuilt, how it is verified that outdated sets are removed rather than sitting next to new ones.
• Resource documentation: purpose of the kit, limits on the number and weight of files per screen — the build stops growing from release to release.
• Sources and master files: layers, guides, text without rasterization. Any edit is made from the master, without quality loss and redrawing.

Before handoff, the kit passes acceptance according to this same list: we check that every element from the design has a file in all densities and that the names match the documentation.

Describe the task — we will return with an estimate and a graphics preparation plan for your release cycle.

Case study: removed blur on large screens and excess weight

We had an interface that looked frankly soft on tablets and large flagships: underneath the graphics was a single set of raster images, and the system stretched it to the required density at render time. At the same time, each screen pulled its own full-size files, some of which were not used at all.

What we did

• Laid out the graphics across five density sets — mdpi, hdpi, xhdpi, xxhdpi, and xxxhdpi — so the system takes a ready file of the required scale instead of calculating it on the fly.
• Converted icons, indicators, and linear elements to vector: they stopped depending on screen density entirely.
• Assembled stretchable backgrounds and buttons into nine-patch images — instead of a dozen separate images for each state.
• Wrote export rules directly in the Figma designs so new screens would not bring the problem back.
• Cleaned out duplicates and unused files, leaving exactly one source per logical resource.

Result

App weight dropped from 68 to 41 MB — almost 40%, even though there are more graphic sets. Blur on large screens disappeared completely: scaling from raster is no longer performed.

Resource building stopped being the longest part of the release, and designers hand over the design using a single set of rules instead of back-and-forth with development.

How vector graphics differs from raster in a project

Raster stores ready pixels, vector stores geometry and the rules for drawing it.

While an image is displayed at its original size, the difference is not visible, but when graphics are scaled, raster is interpolated and contours lose sharpness, while vector is recalculated for the required screen density.

For Android, choosing a format is always a compromise between sharpness on different screens and app weight:

The rule is simple: icons and illustrations go to vector, photographic material and textures remain raster. Blending formats blindly gives either blurry elements on large screens or extra hundreds of kilobytes in the build for every size.

We fix this rule in the project regulation and check it at the build stage: extra raster copies do not get into the app, and icons do not grow into several files for each density.

Technical doubts worth resolving before start

Before development starts, the client asks the same set of questions: what will happen to graphics on different phones, can the design be adjusted without releasing a new version, and what to do if the original designs are gone.

None of them requires an architecture review, but each affects the scope of asset preparation and timelines. Below are short answers to resolve doubts before estimation.

Can graphics be changed without releasing a new version?

Part of the design — yes: banners, promo blocks, and seasonal collections are moved to a remote resource set; it changes on the server side. The icon, splash screen, and navigation elements remain inside the build.

We fix the list of both before the start so that it does not later turn out that a needed block cannot be updated without publishing.

We don't have the original designs — only screenshots

We convert the logo to vector, scale large elements, and redraw small details and semi-transparent layers on the grid. The scope of this work depends on what has been preserved — we estimate it after reviewing the materials.

Is dark theme a second set of graphics?

No, if colors are built on semantic tokens: one set of images is recolored by the palette, vector icons are reused without edits. Switching between themes works without redrawing or flickering when the system setting changes.

Let's discuss the task: what to send for estimating the scope of work

Screen densities are the main source of non-obvious scope: one icon turns into five sets, and an illustration in a banner turns into a separate export branch.

For the scope estimate to be based on facts rather than guesses, we need the sources and a list of screens where these assets live. Below is the minimum set of input data; from it we estimate effort and return with a graphics work plan.

• Sources in vector or layers: master files of icons, logos, illustrations — with separate layers, not "flattened" copies.
• List of densities: whether mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi are needed in full or whether two or three sets are enough somewhere.
• List of screens and states: where the asset appears, at what size, with which variants — pressed, disabled, loading, error.
• App icon and system elements: main icon, adaptive and round variants, background with foreground layer, store image.
• Format requirements: transparency, WebP or PNG, allowable file weight, and quality loss during compression.
• Dark theme, additional design themes, and language versions — if there is more than one design.
• References and design system: palette, grid, spacings, already assembled exports — so as not to rebuild what works.

To discuss the task, it is enough to describe the product and send what already exists. Gaps in the list do not block estimation — we clarify missing input data with questions and include it as a separate item in the work plan.