Proposal: add `avif` to Android `drawableFileTypes` (like HEIC)

[zereight]

Introduction

Please consider adding avif to the Android drawable whitelist (drawableFileTypes) in:

• packages/assets/path-support.js
• packages/community-cli-plugin/src/commands/bundle/assetPathUtils.js

This is the same kind of allow-list change as Allow Heif/Heic Assets (#54640).

Details

On Android release, require('./foo.avif') is copied using getAndroidResourceFolderName(). Anything not in drawableFileTypes is packed into res/raw/ (1x only). Image / FastImage then resolve the bundled asset as a scheme-less resource name and look it up as drawable, so the AVIF is present in the APK but the view stays empty.

We hit this on React Native 0.84.1 with avif already in Metro assetExts. Debug (Metro HTTP) loaded the same file; release did not, because lookup never reached R.raw.

Android still documents drawable bitmaps as PNG / WEBP / JPG / GIF (Drawable resources). AVIF is listed under supported image formats (decoder from Android 12; mandatory on 14). So this is a packaging-path gap, not “AVIF is not an image”.

Workaround that works today: pass FastImage { uri: 'res:/raw/' + getAndroidResourceIdentifier(asset) } so Glide loads android.resource://{pkg}/raw/….

Open question: I have not verified whether AAPT2 accepts .avif files inside res/drawable-*. If it rejects them, raw is the correct folder and the whitelist should stay as-is — but then resolveAssetSource / Image should look up raw when drawable id is 0, instead of silently clearing the view.

Discussion points

• Should avif be added to drawableFileTypes, matching HEIC?
• If AAPT cannot compile AVIF as a drawable, should Android ImageSource fall back to raw for scheme-less names?
• Should Metro default assetExts include avif, or remain opt-in?

Environment

• React Native 0.84.1
• Android release / require() local AVIF
• minSdk 29, devices with native or Glide/libavif decode