The symptom is instantly recognisable: most of your icons sit inside clean circles or squircles, but a handful appear as shrunken logos floating on white squares, jagged-edged cutouts, or glyphs awkwardly cropped at the corners. These are masking glitches, and they are not random. Every one of them traces back to a specific mismatch between what an icon pack (or an app) supplied and what the launcher expected to clip. Learning to fix missing icon masking glitches in a launcher means learning to diagnose which layer of the adaptive icon system broke — because the fix for a missing background layer is completely different from the fix for a malformed mask declaration.
Fix missing icon masking glitches: a launcher anatomy lesson
An adaptive icon renders in three steps. The app or pack provides a background layer and a foreground layer on a 108dp canvas. The launcher provides a mask path — the shape. Android clips both layers to the mask, showing only the central 72dp safe zone, which is why well-drawn glyphs never touch the edges. Masking glitches happen when any of the three inputs is wrong: a missing background layer, a foreground drawn for the wrong canvas size, or a pack entry that declares itself as a finished flat icon when it is actually a layer meant to be combined. Keep that model in mind and the glitches below sort themselves.
| What you see | Most likely cause | First fix to try |
|---|---|---|
| Logo floating on a white or grey square | Legacy flat icon with no background layer; launcher generated a plain backplate | Set a generated-background colour, or replace the icon from a pack with real layers |
| Glyph cropped at corners or edges | Foreground drawn full-bleed for a different mask shape | Change icon shape; if only one app is affected, override that icon |
| Icon much smaller than neighbours, big empty margin | Foreground drawn with excessive padding for the 108dp canvas | Per-icon replacement; report to the pack author |
| Blurry, upscaled appearance | Low-resolution legacy PNG being stretched | Use a higher-density pack or the app’s own adaptive icon instead |
| Icon reverts to stock after each app update | The app changed its component name; pack mapping broke | Re-apply the pack or re-assign the icon once; wait for pack update |
Fix 1: deal with the white-square fallback properly
The white square is Smart Launcher telling you “this icon arrived with no background, so I generated the safest possible one”. It is most common with older apps whose icons predate adaptive icons entirely. You have three escalating options. Start inside Icon appearance settings, where Smart Launcher lets you control how unthemed/legacy icons are presented: choosing a background colour sampled from, or harmonised with, your pack turns a harsh white tile into a deliberate-looking plate, especially if you match the tint strategy in how adaptive packs are applied. Next, check whether the pack offers an alternate for that app — many packs include a generic glyph (a generic browser globe, a generic mail envelope) that is far better than a raw legacy logo. Last resort, replace the icon individually from another pack or a PNG, as covered in customizing individual app icons. What does not work: repeatedly re-applying the pack. The fallback is deterministic; it will render identically every time.
Fix 2: cropped glyphs and shape mismatches
Cropping happens when a foreground was drawn assuming a square or “squircle-with-generous-corners” mask and you apply a circle or teardrop. System icons from the phone manufacturer are frequent offenders, because OEMs draw for their own default mask. If many icons crop, your chosen shape fights the pack: switch shape in Icon appearance and re-check — the guide to custom icon shapes explains which shapes are safest for mixed libraries. If exactly one app crops, the app’s own icon is badly drawn; override just that icon. Note the subtle case: some apps ship an adaptive icon whose foreground is intentionally full-bleed (a photo, a map). Those will crop by design under any mask; a circle that cuts a face is the app author’s choice, not a bug you can repair, though a per-icon replacement remains available.
Treat these numbers as a starting point: apply them in Smart Launcher 6 under Settings → Home screen → Grid, use the layout for a day, then nudge one value at a time — your wallpaper, widget sizes and one-handed reach all shift what feels right.
Fix 3: when the pack itself declares icons wrongly
Serious masking bugs live in the pack’s own data. Icon packs describe each entry in appfilter.xml; an entry can point to a plain drawable (treated as finished art) or to an adaptive-icon XML with foreground/background items. If an author mistakenly registers a bare foreground layer as a finished icon, you get a floating glyph with no background — identical symptom to the legacy case, different culprit. You cannot edit a pack’s XML as a user, but you can route around it: that icon, replaced individually, or a different pack. In Icon Pack Studio, by contrast, you can fix this class of problem for packs you generate yourself, because the studio rebuilds the layer declarations when it exports. This is also why “the same pack looks fine in another launcher” happens: launchers differ in how generously they synthesise missing backgrounds, so a marginal pack can look acceptable in one and broken in another. Smart Launcher’s behaviour follows the platform model strictly, which exposes sloppy pack data rather than papering over it.
Fix 4: stale caches and icons that will not refresh
Sometimes the data is right and the picture is stale: you updated a pack, but the home screen still shows the old broken rendering. Smart Launcher caches rendered icons; a pack update normally invalidates the affected entries, but a confused cache clears fastest by re-applying the pack from Icon appearance (toggle to a different pack, then back) or restarting the launcher from its settings. Avoid the nuclear habit of clearing all launcher data for an icon problem — that erases your layout and overrides along with the cache. And if a single app’s icon broke right after that app updated, suspect the component-name change from the table above: the pack is fine, the mapping is orphaned, and the durable fix arrives with the pack’s next update. The rest of the Icon Customization library covers the adjacent rendering problems, like DPI-related softness.
When to stop fixing and switch packs
There is a threshold where per-icon repair stops being maintenance and becomes unpaid labour for the pack author. If more than a fifth of your library shows masking faults — not fallbacks for missing apps, but broken rendering of covered apps — the pack’s data is poor and will stay poor; every update risks new breakage. Switch to a pack built on the adaptive model and your fixes drop to the odd missing app. Conversely, if faults concentrate in two or three apps while the other hundred render perfectly, the pack is fine and those apps are the problem — override them and move on. Diagnosing which situation you are in is the whole skill: count the broken icons before you fix a single one, because the count, not the annoyance of any individual icon, tells you where the fault lives.
Frequently Asked Questions
Why do only a few icons have white squares behind them?
Those specific apps or pack entries lack a background layer. Everything with proper adaptive layers masks cleanly; the few legacy or misdeclared icons get a generated backplate, which defaults to a plain light colour. Fix them individually or set a generated-background colour that matches your pack.
Does changing the icon shape fix cropped icons?
Often, yes. Cropping usually means the foreground was drawn for a roomier mask than the one you selected. Trying a squircle or rounded square restores the corners for most icons. A single stubborn app can then be replaced individually instead of compromising the whole set’s shape.
Is a masking glitch the pack’s fault or Smart Launcher’s fault?
Usually the data’s fault: a missing layer, a wrongly declared entry, or a foreground drawn outside the safe zone. Launchers can only clip what they are given. Smart Launcher follows the standard adaptive-icon model, so packs built to that model render correctly; packs with sloppy data are exposed by it.
Will reinstalling the icon pack fix broken masking?
Reinstalling rarely changes anything, because the pack’s data is identical after reinstall. What helps is re-applying the pack inside Smart Launcher (which rebuilds the icon cache), updating the pack if a newer version exists, or overriding the affected icons individually.
Can Icon Pack Studio repair a pack with masking problems?
For packs you generate yourself, yes — the studio rebuilds layer declarations on export, so a converted set often masks more cleanly than its source. For a third-party pack installed as-is, you cannot edit its declarations, but you can use it as conversion source material in the studio.
