Maps Compose: KML/KMZ parsing crashes with NoSuchMethodError when the app also uses xmlutil 1.0.x (transitive android-maps-utils 5.0.0)

[jamesarich]

Environment details

1. API: Maps Compose (maps-compose / maps-compose-utils / maps-compose-widgets 8.4.0)
2. Android (any OS version; reproduced on Android 12–17 devices in production)
3. maps-compose 8.4.0 → maps-utils-ktx 6.2.0 → android-maps-utils 5.0.0, in an app that also resolves io.github.pdvrieze.xmlutil ≥ 1.0.0 (directly or transitively — e.g. any library using xmlutil for its own XML handling)

Steps to reproduce

1. Depend on maps-compose-utils 8.4.0 and on io.github.pdvrieze.xmlutil:serialization:1.0.x (Gradle's conflict resolution picks 1.0.x over android-maps-utils-data 5.0.0's 0.91.3 request).
2. Parse any KML document: KmlParser().parse(stream) (com.google.maps.android.data.parser.kml).
3. Fatal crash on the parser's first use.

Code example

// with io.github.pdvrieze.xmlutil:serialization:1.0.2 also on the runtime classpath
KmlParser().parse(kmlStream) // → NoSuchMethodError

Stack trace

java.lang.NoSuchMethodError: No virtual method policyBuilder()Lnl/adaptivity/xmlutil/serialization/DefaultXmlSerializationPolicy$Builder; in class Lnl/adaptivity/xmlutil/serialization/XmlConfig$Builder;
    at com.google.maps.android.data.parser.kml.KmlParser.xml$lambda$0(...)

Analysis

android-maps-utils-data:5.0.0's published bytecode calls xmlutil 0.91.x's XmlConfig$Builder.policyBuilder(), which xmlutil 1.0.0 removed. This was already fixed in android-maps-utils via googlemaps/android-maps-utils#1741 (uses the 1.0.x XmlConfig$CompatBuilder API) and shipped in android-maps-utils 5.1.0+ — and maps-utils-ktx 6.3.0 already carries 5.1.0. Maps Compose is the last link still pinning mapsktx = 6.2.0, so every Maps Compose consumer whose dependency graph contains xmlutil 1.0.x gets crashing KML/KMZ support.

The fix is already open in this repo: #957 (and dependabot's #968 covers the same mapsktx bump). Filing this to attach real-world severity to those PRs: this is a production crash, not a routine dependency refresh — in Meshtastic-Android it was our #1 fatal by event count on our current release (KML map-overlay import 100% broken, users retrying ~5x each) until we worked around it by force-raising android-maps-utils to 5.1.1 directly (meshtastic/Meshtastic-Android#6811). A maps-compose release with the ktx 6.3.0 bump would let downstream apps drop that workaround.