[Help Wanted] Testing/verification: Verify the AMap provider (#49)

[parawanderer]

#49 merged @SadGare's fork, which brought the IMapProvider abstraction and the AMap (高德地图) implementation. Nobody on the maintainer side can test AMap: it needs a mainland-Chinese developer account with real-name verification, plus an API key bound to the package name and signing fingerprint. So it went in verified by review and reasoning rather than by running it, and this issue is the honest record of that.

What is actually unverified

Less than it might sound. Since @SadGare's own last commit, AMapProvider.java has had exactly one change — 27 lines adding marker draw order, both halves reflective like the rest of the class and wrapped so that a failure degrades to an unordered marker rather than no marker:

try {
    java.lang.reflect.Method zIndexMethod = markerOptionsClass.getMethod("zIndex", float.class);
    zIndexMethod.invoke(markerOptions, marker.getZIndex());
} catch (Exception e) {
    Log.w(TAG, "Could not set the marker draw order; overlapping tags may not raise on selection", e);
}

Everything else in that file is the contributor's code as written. The rest of the merge — key alignment, the import path, the history fetch — is provider-agnostic and was verified on a physical device against live Apple.

It is also opt-in twice: AMap requires a user-supplied API key, and selecting it without one does not save (c7b3b87, 54506ed). Anyone who has not deliberately fetched a key from the AMap console is on Google Maps and never reaches this code.

What would be useful to confirm

@SadGare — if you have a build with your key set up, could you check these? Each is a thing this branch could plausibly have broken, rather than a general "does it work".

• The map renders at all, and switching provider in Settings then reopening the app keeps the choice
• Markers appear in the right places. The coordinate conversion (CoordinateConverter.wgs84ToGcj02) is untouched, but the reports feeding it now come from a rewritten fetch path
• The selected tag's marker is drawn above the others. This is the 27-line change. Tags kept in the same place resolve metres apart and overlap completely at normal zoom, so tapping a card should visibly raise its marker. If it does not, the log will carry Could not set the marker draw order or Failed to re-order marker — that is a rename in the AMap SDK, not a crash
• Tapping a marker scrolls to its card and raises it
• The history screen draws its polyline and the day navigation works
• Nothing in logcat from AMapProvider at W or E during normal use

A "yes to all" is enough to close this. A "no" on any single item is more useful than a general impression — the reflective calls fail individually and quietly by design, so partial breakage is the expected failure mode rather than a crash.

If it turns out to be broken

The most likely cause is the reflection itself: every AMap class and method is looked up by string, so any SDK rename fails at runtime with a log line instead of at compile time. #51 proposes replacing it with direct calls — the SDK is a normal compile-classpath dependency, so nothing forces the reflection, and doing it would turn exactly this class of failure into a build error. Worth doing while someone who can actually run AMap is available to re-check.

Anyone with the ability to test this is very welcome to weigh in — a screenshot of the map with two overlapping tags, one selected, would answer most of the list on its own.

---

Issue co-authored by Claude Code.