The gap
GoogleMapProvider and AMapProvider have no tests at all. Every screen test runs against
FakeMapProvider, so a change to MapMarker, MapPolyline or IMapProvider can break both real
providers while the entire suite stays green.
This matters more than an ordinary coverage gap because adding a provider is an advertised
extension point — rule 7 in AGENTS.md invites it, and notes that a third party added MapLibre in
about eighty lines. Somebody following that invitation gets no safety net, and the tests will
actively reassure them.
Why it is not simply fixed
Neither can run on the managed device:
aosp-atd carries no Play Services, so Google's map cannot initialise
- the AMap SDK is optional at compile time and
AMapProvider reaches it entirely by reflection
A google system image would cover the first. Nothing covers the second without the SDK present.
What has been done
CoordinateConverterTest (JVM, 6 tests, milliseconds) now covers the GCJ-02 conversion, which was
the one piece that is pure arithmetic. It was worth doing first out of all proportion to its size:
a wrong conversion does not fail, it puts every pin a few hundred metres from the tag for every
user in mainland China, and nothing else in the app would notice.
That leaves the provider classes themselves.
Divergences already spotted, untested
- Google handles all three icon modes (
iconBitmap, iconResourceId, useDefaultIcon); AMap
handles only the bitmap and silently ignores iconResource. Nothing uses iconResource
today, so it is latent rather than broken.
AMapProvider converts WGS-84 to GCJ-02 on the way out (markers, polylines, camera) and back on
the way in (map clicks, getCameraPosition). That symmetry is what keeps the app's internal
coordinates uniformly WGS-84, and nothing checks it holds for any newly added call.
Options, roughly in order of value
- A contract test run against every provider — a small suite asserting the shared promises
(addMarker returns marker.getId(), removeMarker removes it, coordinates round-trip) that
any new provider must pass. Would need a device with Play Services for the Google case.
- A
google managed device profile, opted into rather than default, so the Google provider gets
basic coverage without slowing every run.
- Accept it and write it down — a note in
AGENTS.md rule 7 saying the providers are
untested and a change to IMapProvider needs manual checking on both.
Option 3 costs nothing and is honest; the others are real work. Even done alone, 3 is better than
the current position, where the gap is invisible.
🤖 Written by Claude Code
The gap
GoogleMapProviderandAMapProviderhave no tests at all. Every screen test runs againstFakeMapProvider, so a change toMapMarker,MapPolylineorIMapProvidercan break both realproviders while the entire suite stays green.
This matters more than an ordinary coverage gap because adding a provider is an advertised
extension point — rule 7 in AGENTS.md invites it, and notes that a third party added MapLibre in
about eighty lines. Somebody following that invitation gets no safety net, and the tests will
actively reassure them.
Why it is not simply fixed
Neither can run on the managed device:
aosp-atdcarries no Play Services, so Google's map cannot initialiseAMapProviderreaches it entirely by reflectionA
googlesystem image would cover the first. Nothing covers the second without the SDK present.What has been done
CoordinateConverterTest(JVM, 6 tests, milliseconds) now covers the GCJ-02 conversion, which wasthe one piece that is pure arithmetic. It was worth doing first out of all proportion to its size:
a wrong conversion does not fail, it puts every pin a few hundred metres from the tag for every
user in mainland China, and nothing else in the app would notice.
That leaves the provider classes themselves.
Divergences already spotted, untested
iconBitmap,iconResourceId,useDefaultIcon); AMaphandles only the bitmap and silently ignores
iconResource. Nothing usesiconResourcetoday, so it is latent rather than broken.
AMapProviderconverts WGS-84 to GCJ-02 on the way out (markers, polylines, camera) and back onthe way in (map clicks,
getCameraPosition). That symmetry is what keeps the app's internalcoordinates uniformly WGS-84, and nothing checks it holds for any newly added call.
Options, roughly in order of value
(
addMarkerreturnsmarker.getId(),removeMarkerremoves it, coordinates round-trip) thatany new provider must pass. Would need a device with Play Services for the Google case.
googlemanaged device profile, opted into rather than default, so the Google provider getsbasic coverage without slowing every run.
AGENTS.mdrule 7 saying the providers areuntested and a change to
IMapProviderneeds manual checking on both.Option 3 costs nothing and is honest; the others are real work. Even done alone, 3 is better than
the current position, where the gap is invisible.
🤖 Written by Claude Code