chore: suppress the three lint checks that are wrong here, with reasons

[almothafar]

Part of #245. Clears 8 warnings that are not defects: 2 InlinedApi, 1 UnusedAttribute, 5 IconLauncherShape.

lintDebug: 35 → 27 warnings. Independent of #254 and #255 — all three can merge in any order.

Per the issue's ground rules, every suppression is scoped as narrowly as the mechanism allows and carries a reason. No lint-baseline.xml.

InlinedApi ×2 — safe, and worth explaining why

BatteryManager.EXTRA_CYCLE_COUNT is API 34, minSdk 26. The reason this is harmless is that it's a compile-time String constant — javac inlines the literal, so nothing is resolved at runtime and there's no NoSuchFieldError on an older device. It just reads an extra that isn't in the Intent and gets the default. Both sites already normalise a missing value to -1.

Suppressed on the local variable declaration, not the enclosing method, so the rest of each method stays checked.

UnusedAttribute — the intended state

android:localeConfig is read on API 33+; minSdk is 26. That's exactly the intent of #48 — older devices fall back to the in-app language choice AppCompatDelegate stores. tools:ignore on <application> is the only scope the manifest offers, so there's a comment naming localeConfig specifically.

IconLauncherShape ×5 — needs lint.xml

A PNG has nowhere to put an annotation, so this is the one that needs a config file. It lists the five files individually rather than disabling the check, so a genuinely bad icon added later still gets flagged.

The reasoning: these are the legacy raster launcher icons. The real icon is the adaptive one (#236) — it has the safe zone and the launcher mask. A legacy raster has neither, so filling its square is what it's supposed to do. The guidance lint quotes is about adaptive icons.

Two things I noticed but did not touch

Both are outside this issue's scope, and I'd rather flag them than quietly fold them in:

1. Those five PNGs may be dead weight entirely. minSdk is 26 and the adaptive icon lives in mipmap-anydpi-v26, and anydpi takes precedence over every density bucket — so on every supported device @mipmap/ic_launcher resolves to the XML, never to a PNG. I did not delete them: some OEM launchers and backup UIs read density mipmaps directly, and chore: get lintDebug to zero warnings and keep it there #245 explicitly chose suppression over redrawing here.

2. The notification's large icon is probably null. NotificationService:654 does BitmapFactory.decodeResource(res, R.mipmap.ic_launcher) and feeds it to setLargeIcon. Given the resolution order above, that call almost certainly hits the adaptive-icon XML, and decodeResource returns null for an XML drawable — so the notification would silently show no large icon rather than crash. I'm reasoning from resource-resolution rules, not from a device, so treat it as "worth checking": pull down your notification shade and see whether the app icon appears on the right of the alert. If it doesn't, that's a real bug and wants its own issue — the fix is AppCompatResources.getDrawable(...) plus toBitmap(), or IconCompat.createWithResource.

Verification

• lintDebug: 35 → 27, zero InlinedApi, zero UnusedAttribute, zero IconLauncherShape.
• Unit tests and assembleDebug pass.
• No runtime behaviour changes in this PR — it's annotations, a manifest attribute and a new config file.

🤖 Generated with Claude Code