Android maps start at the home base

Summary

The owner asked (2026-10-20) that Android’s map shows the home base when a flight is opened, as iOS does. Android sets and syncs the home base since Android settings parity, but no Android screen reads it yet: its map view is created without a camera, so it starts at Mapbox’s default, the whole world at zoom 0.

iOS gives every map a starting camera before it is shown (MapViewDataSource.setupMap() → centerToInitialLocation(), vulture-ios/Modules/App/Sources/Map/MapViewDataSource+Center.swift):

	iOS	Android today
Starting camera	The current home base, zoom 9, north up; without one, Klippeneck (48.1049991, 8.7470783)	None (Mapbox’s default, 0°, 0°, zoom 0)
A map with nothing to frame	Fades in at the home base once the style has loaded (shouldCenterWithoutContent)	Fades in on the whole world
A map with a flight or task	Stays hidden until the first frame, then frames it from the home base	The same, framed from the whole world

Behaviour

Android follows iOS; iOS does not change.

• Starting camera. The flight map and the task map (both MapboxFlightMapController) start centred on the current home base at zoom 9, bearing 0. Without a home base: Klippeneck, 48.1049991, 8.7470783 (HomeBase.MAP_FALLBACK, iOS’s fallbackCoordinate).
• Nothing to frame. A flight map without a decodable flight, or a task map without a task, fades in there once the style has loaded.
• A flight or a task. Unchanged: the map stays hidden until the first frame. An animated first frame now eases from the home base, not from the whole world.
• A kept camera (the screen restores the camera it had, restoreCamera) still wins over the home base.
• The home base changes while a map is open (on another device, synced): the open map does not move; the next map that opens uses the new one. On iOS, the task map’s recents menu re-centres on the home base the pilot picks there; Android’s task map has no such menu, and this analysis does not add one.
• Read once. The home base is read when the map is created: no map waits for settings to load. If the settings are not loaded yet, use the fallback rather than delaying the map.

Data

None. Reads SyncedSettings.homeBase (SettingsRepository.homeBase).

APIs

None.

Strings

None.

Decisions

#	Question	Decision	Date
1	Which maps?	The flight map and the task map, which share the controller (iOS does both).	2026-10-20
2	Zoom and fallback	As iOS: zoom 9, Klippeneck 48.1049991, 8.7470783.	2026-10-20
3	A home base changed while the map is open	No re-centring; the next map uses it.	2026-10-20

Decisions 1 and 3 are defaults taken while writing this up; the owner can overrule them.

Open questions

None.

Platforms

iOS

No changes.

Android

Code (vulture-android)	Change
core/map/.../flightmap/FlightMap.kt (MapInitOptions)	Pass the starting camera (cameraOptions: the centre, zoom 9, bearing 0) when the map view is created
core/map/.../flightmap/MapboxFlightMapController.kt	Unchanged reveal (presentIfReady): a map with nothing to frame now fades in on the home base
feature/flightmap/.../FlightMapScreen.kt, its view model; feature/taskmap/.../TaskMapScreen.kt, its view model	Give the map its starting centre: SettingsRepository.homeBase’s coordinate, else HomeBase.MAP_FALLBACK

Tests: the starting camera with and without a home base; a restored camera still wins. Screenshot of an empty flight map. Changelog (“The map opens on your home base”).

Web

No changes.

Tasks

• vulture-android: the starting camera on the flight and task maps; tests; changelog (2026-10-20). No screenshot of an empty flight map: Mapbox does not render on Robolectric, so the screen tests check the centre the map is given and a unit test the camera built from it.
• vulture-docs: when built, update Home base (Android reads it now), the home base note in Port decisions §15, and set status: shipped.