enhance(android): nearby marker 2D and 3D type

[DharaneshSP]

Does any other open PR do the same thing?

(please answer here)

What issue is this PR fixing?

(please link the issue here)

How did you test this PR?

(please answer here)

[prakharritik]

The left/right icon split and the 2D/3D caching approach are sensible. Three concrete issues to fix.

[prakharritik]

Memory leak: icon caches are never cleared when markers are removed.

When a driver/bus marker is removed (the iterator loop at the end of updateNearbyMarkersFromProcessedData), the code cleans up markerAnimators and nearbyMarkersCalloutCache for that driverId, but not these two icon caches. BitmapDescriptor wraps a native Android Bitmap which is a large unmanaged object. Over a long session where buses continuously appear and disappear, this will cause steady memory growth.

Add the corresponding remove calls in the cleanup block alongside nearbyMarkersCalloutCache.remove(driverId):

nearbyMarker2DIconsCache.remove(driverId);
nearbyMarker3DIconsCache.remove(driverId);
nearbyMarkersCalloutCache.remove(driverId);

[prakharritik]

Redundant setVisible call.

existingCalloutMarker.setVisible(isVisible && !hideCallout) is called unconditionally at line 2261, immediately after the existingCalloutMarker != null guard. This else branch (reached only when !forceUpdate) calls it again with exactly the same arguments — it's a no-op. Remove the duplicate:

if(existingCalloutMarker != null){
    existingCalloutMarker.setVisible(isVisible && !hideCallout);
    if(forceUpdate){
        // ... icon update logic
    }
    // no else needed — visibility already set above
}

[prakharritik]

Non-idiomatic Java: forceUpdate == false should be !forceUpdate.

Comparing a boolean to false with == is valid but non-idiomatic. Use !forceUpdate instead:

} else if (!forceUpdate) {
    rotation = existingMarker.getRotation();
}