FileProvider declaration collides with host app's FileProvider in the manifest merger

[jkmassel]

Summary

GBK's Android manifest declares <provider android:name="androidx.core.content.FileProvider"> directly, which the AGP manifest merger treats as a duplicate of any host app's own FileProvider — regardless of android:authorities. Host apps that already declare a FileProvider with the canonical AndroidX class name (the documented pattern) hit a build failure on first integration of v0.17.x and have to retrofit tools:replace to ship.

Repro

Host app's AndroidManifest.xml:

<provider
    android:name="androidx.core.content.FileProvider"
    android:authorities="${applicationId}.provider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/provider_paths"/>
</provider>

After upgrading to org.wordpress.gutenbergkit:android:v0.17.1:

Attribute provider#androidx.core.content.FileProvider@authorities
  value=(com.example.app.provider) from (unknown)
  is also present at [org.wordpress.gutenbergkit:android:v0.17.1]
  AndroidManifest.xml:19:13-74
  value=(com.example.app.gutenberg.fileprovider).
Suggestion: add 'tools:replace="android:authorities"' to <provider>
  element at AndroidManifest.xml to override.

A second error on the FILE_PROVIDER_PATHS meta-data resource (@xml/provider_paths vs @xml/gbk_file_paths) follows the same shape.

Root Cause

Per the manifest merger docs, <provider> elements are matched by android:name. Two declarations of androidx.core.content.FileProvider are treated as the same element; conflicting android:authorities and child meta-data become hard errors.

The current manifest comment in Gutenberg/src/main/AndroidManifest.xml:

Authority is keyed off the host app's applicationId so it won't collide with one a host app already declares.

— is correct at the Android runtime layer (where providers route by authority), but the AGP manifest merger collides earlier, on the class name. The runtime-uniqueness guarantee doesn't help the build.

Suggested Fix

Subclass FileProvider:

// android/Gutenberg/src/main/java/org/wordpress/gutenberg/GutenbergFileProvider.kt
package org.wordpress.gutenberg
import androidx.core.content.FileProvider
class GutenbergFileProvider : FileProvider()

<provider
    android:name="org.wordpress.gutenberg.GutenbergFileProvider"
    android:authorities="${applicationId}.gutenberg.fileprovider"
    ... />

FileProvider has a public no-arg constructor; the subclass adds nothing but a unique android:name. The merger now keys on a distinct class, the host app's FileProvider stays untouched, and consumers need no workaround.

This is the same pattern Chucker uses (ChuckerFileProvider), which is why Chucker coexists with a host-declared androidx.core.content.FileProvider without ever surfacing this issue.

Consumer Workaround (for now)

Hosts integrating v0.17.x today need to fold the GBK authority and paths into their own provider:

<provider
    android:name="androidx.core.content.FileProvider"
    android:authorities="${applicationId}.provider;${applicationId}.gutenberg.fileprovider"
    android:exported="false"
    android:grantUriPermissions="true"
    tools:replace="android:authorities">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/provider_paths"
        tools:replace="android:resource"/>
</provider>

…and copy gbk_camera (<cache-path name="gbk_camera" path="camera/"/>) into the host's provider_paths.xml. Awkward, and easy to forget on subsequent GBK updates if GBK ever adds more paths.

Affected

• org.wordpress.gutenbergkit:android:v0.17.0 and later (introduced when the camera-capture FileProvider landed).