feat(android): render branded block icons with contrast-aware tinting

[jkmassel]

Stacks on top of #461 (native block inserter). Renders block icons via AndroidSVG, with contrast-aware tinting so branded icons read correctly against either a light or dark dialog surface.

This PR is two related slices that land together — splitting them would just be churn:

• Render SVG icons (commit a315e2f) — adopts AndroidSVG (com.caverock:androidsvg-aar:1.4) and mirrors BlockIconCache on iOS. Handles three @wordpress/icons quirks the browser papers over with CSS: missing viewBox (e.g. core/site-tagline), root fill="none" (e.g. core/icon), and multi-fill branded icons that would flatten under a PorterDuff tint.
• Contrast-aware tinting (commit a6accad) — addresses the "known limitation" called out in the first commit. Pipes icon.foreground through the JS bridge so single-colour brand icons (Pocket Casts red) render correctly, and adds a 3:1 WCAG contrast check so low-contrast brands (X #000000, Dailymotion #333436, WordPress Embed #0073AA) fall back to the theme tint instead of disappearing into the surface.

Screenshots

Pixel 9 Pro XL. The embed section is the interesting one — it exercises every branch of the tinting decision (monochrome, multi-colour branded, single-colour branded with good/bad contrast).

Embeds

Dark	Light

In dark mode, WordPress (#0073AA), X (#000000), and Dailymotion (#333436) fall back to the theme tint — all three fail the 3:1 contrast check against the chip surrogate. In light mode the same colours pass and render as-is. Pocket Casts / Reddit / Pinterest / Spotify / YouTube / Vimeo keep their brand colours in both modes (multi-colour or sufficient contrast).

Most used

Dark	Light

Bridge

getBlockIcon at src/utils/blocks.js:44 previously dropped icon.foreground — the JS metadata that the web editor applies as CSS color, which paths inside the SVG pick up via currentColor. Adds getBlockIconForeground and includes it in the serialised inserter payload, with matching iconForeground: String? fields on the Android BlockType data class and the iOS BlockType struct (iOS gets the field for parity; no rendering change).

Chip background

Wraps each icon in a 44dp RoundedRectangle chip filled with ~12% of the theme's primary text colour, mirroring the iOS BlockIconView treatment (Color(.label).mask over a secondarySystemFill chip). Without this, low-contrast brand icons rendered as near-invisible smudges on the dark bottom sheet.

Tinting decision

SvgIconCache.shouldTint decides per-icon whether to apply the theme tint:

1. No declared colours — pure monochrome; tint to text colour.
2. Multiple declared colours (Pocket Casts red+white, Animoto, Bluesky) — render as-is. A PorterDuff SRC_IN tint would flatten internal contrast into a silhouette.
3. Single declared colour — keep it if it has at least 3:1 contrast (WCAG 2.x SC 1.4.11 — minimum for UI graphics) against the surface the icon actually sits on; otherwise strip the brand colour and tint.

The contrast reference is the chip fill composited over the dialog surface, not the bare surface. Measuring against bare black makes marginal colours like WordPress blue (#0073AA) appear to pass at 3.16:1 while reading as dim against the actual ~#3B3B3D chip surrogate (2.1:1). resolveDialogSurface() looks up ?attr/colorSurface then ?android:attr/colorBackground so the surrogate matches what the user sees.

Test plan

• ./gradlew :Gutenberg:test detekt :Gutenberg:lintDebug :app:compileDebugKotlin — BUILD SUCCESSFUL
• Manually verified on Pixel 9 Pro XL with enableNativeBlockInserter on, dark theme: Pocket Casts renders red+white, Animoto/Bluesky render branded, X / Dailymotion / WordPress Embed render white (tint fallback), Site Tagline / Icon block still render correctly.
• Manually verified on Pixel 9 Pro XL, light theme: WordPress / X / Dailymotion render in brand colour (pass contrast against the light chip), branded multi-colour icons unchanged.
• Reviewer: verify iOS behaviour unchanged.

Related

• Builds on feat(android): add native block inserter #461

[adalpari]

It looks good, but Claude found these three points I believe woult be gret to review:

Issues                    
        
- resolveTextColorPrimary has no fallback — can throw NullPointerException
                                                                                                                                                                                  
  BlockInserterDialog.kt:310–314                                                                                                                                                  
                                                                                                                                                                                  
  private fun Context.resolveTextColorPrimary(): Int {                                                                                                                            
      val typed = TypedValue()
      theme.resolveAttribute(android.R.attr.textColorPrimary, typed, true)
      return resources.getColorStateList(typed.resourceId, theme).defaultColor
  }                                                                                                                                                                               
   
  resolveAttribute can return false (attribute absent), leaving typed.resourceId == 0. getColorStateList(0, …) throws. resolveDialogSurface next to it handles this correctly with
   a for loop + fallback. This should do the same.
                                                                                                                                                                                  
  ---                       
- BlockViewHolder uses positional child access — fragile
                                                                                                                                                                                  
  BlockInserterDialog.kt:146–149
                                                                                                                                                                                  
  private val icon = (container.getChildAt(0) as FrameLayout).getChildAt(0) as ImageView
  private val textContainer = container.getChildAt(1) as LinearLayout                                                                                                             
  private val title = textContainer.getChildAt(0) as TextView
  private val description = textContainer.getChildAt(1) as TextView                                                                                                               
                            
  Any future change to the view hierarchy (e.g. inserting a badge or reordering children) silently breaks binding or crashes at runtime. The standard approach is to hold         
  references directly when building the view in buildBlockView/buildIconChip, then pass them into the ViewHolder constructor.
                                                                                                                                                                                  
  ---                       
- rightMargin used instead of marginEnd — breaks RTL layouts
                                                               
  BlockInserterDialog.kt:242
                                                                                                                                                                                  
  layoutParams = LinearLayout.LayoutParams(chipSizePx, chipSizePx).apply {
      rightMargin = rightMarginPx                                                                                                                                                 
  }                         
                                                                                                                                                                                  
  rightMargin is physical; marginEnd is layout-direction-aware. On RTL devices the icon chip should trail the text, not lead it. Use MarginLayoutParamsCompat.setMarginEnd() or   
  layoutParams.marginEnd = rightMarginPx.
                                                      

[adalpari]

Thank you for the changes! LGTM!