Android settings parity, and the home base from the airports
Summary
Section titled “Summary”The owner asked (2026-10-20) for three iOS settings on Android:
| Setting | Android today | This analysis |
|---|---|---|
| Clear cloud overlay cache | Already there: Settings › Advanced, next to Clear map artwork (65dfb42d, analysis SkySight clouds on Android) | Nothing to build |
| Client-side tracking toggle | Missing (Privacy and telemetry is partial) | Add it |
| Set your home base | Omitted on purpose (P9-D3: no Android screen used it) | Add it |
And one change for both platforms: the home base is picked from the bundled airports table (Take-off airfield), no longer from the waypoint files. Android has the table since the take-off airfield, and has no waypoint files.
Behaviour
Section titled “Behaviour”Client-side tracking (Android)
Section titled “Client-side tracking (Android)”- A switch in Settings › Advanced, in iOS’s place: after the two caches, before Mapbox telemetry. Title and subtitle
as iOS (
settings.label.tracking,settings.label.tracking.title), in the 8 languages. - On by default, per device, not synced: iOS keeps it as the Mixpanel SDK’s opt-in state, per device too.
- What it switches: Android sends no usage analytics today (no analytics SDK; paywall events are logged locally), so the switch only stores the choice. Any analytics added later must read it and send nothing when it is off.
- It does not switch Crashlytics’ crash reports (P8B-D15), which are not usage tracking. The subtitle says nothing about crashes, so this matches what the pilot reads.
The home base, on both platforms
Section titled “The home base, on both platforms”Where: Settings › General, the row “Set your home base” after Units, with the current home base’s name as its
subtitle (iOS: MainSettingsDestination.homebase, today with the “Klippeneck” fallback when none is set; Android:
the same row and fallback).
The picker (new on both; on iOS it replaces the waypoint list for the home-base purpose only):
| Part | Rule |
|---|---|
| Recent | The recent home bases, newest first, at most 5 (the homebases records), the current one ticked |
| Search | A search field over the airports table: matches the code (e, e.g. EBZW) and the name (a), without regard to case or accents |
| Results | Without a search: the airfields nearest to the current home base (or, without one, to the device’s last known position, if allowed), 50 at most, nearest first, with their distance. With a search: the matches, the exact code match first, then by name |
| A row | The name (a), the code and the country’s flag (d), e.g. “Genk · EBZW 🇧🇪” |
| Choosing | Makes it the current home base, adds or moves it to the top of the recents, and goes back |
| Reset | iOS’s “reset home base” stays, as it is today |
What is stored (unchanged format, Sync schema): name, latitude, longitude.
The name of an airport home base is “a (e)”, e.g. “Saint Hubert (EBSH)”: the code keeps two airfields
of the same town apart (Saint Hubert is both EBSH and EBSU), and the homebases id is a hash of the name. Existing
home bases (waypoint names such as “St Hubert Gld”) stay valid and keep working; they are simply no longer offered
except as recents.
What uses it: unchanged on iOS (centring empty maps, the home symbol on the map, the task map’s recents menu, the widgets, in-flight). On Android it is set and synced, so a home base chosen on an Android phone reaches the pilot’s other devices; no Android screen reads it yet, as before (P9-D3’s reason still holds for the map).
Go-to target (iOS, unchanged)
Section titled “Go-to target (iOS, unchanged)”The same picker also chooses the in-flight go-to target (purpose: .goTo). That purpose keeps the waypoint files.
- Android, tracking: a new local (not synced) setting in
LocalSettings, defaulttrue. - Home base: no format change. Android writes the
homeBasesynced setting and thehomebasesrecords it so far only kept untouched (Persistence and settings).
None.
Strings
Section titled “Strings”- Android:
settings_label_tracking,settings_label_tracking_title, and the home base row and picker texts, from iOS’s text and translations (settings.label.tracking*,settings.title.homebaseand the picker’swaypoint.selection.*home-base strings). - iOS: none new, unless the picker’s empty search result needs one (“No airfield found”): reuse the waypoint picker’s no-results text.
Decisions
Section titled “Decisions”| # | Question | Decision | Date |
|---|---|---|---|
| 1 | Clear cloud overlay cache on Android? | Already built (65dfb42d); nothing to do. | 2026-10-20 |
| 2 | The tracking switch without an analytics SDK? | Store the choice per device, default on; future analytics must respect it. Crashlytics is not affected. | 2026-10-20 |
| 3 | Where does the home base come from? | The airports table, on both platforms (owner); iOS stops offering waypoint files for it. | 2026-10-20 |
| 4 | Home base name for an airfield | “a (e)”, so two airfields of one town stay apart. | 2026-10-20 |
| 5 | What Android does with the home base | Set and sync it; no Android screen reads it yet. | 2026-10-20 |
| 6 | How many matches does a search list? | At most 100, the exact code first, then by name: a single letter would otherwise list most of the world’s 48 000 airfields (iOS implementation). | 2026-10-20 |
| 7 | iOS’s “reset home base” | There was none to keep: the old picker could reset the home base in code, but no button offered it, so the new picker has none either (iOS implementation). | 2026-10-20 |
Decisions 2, 4 and 5 are defaults taken while writing this up; the owner can overrule them.
Open questions
Section titled “Open questions”None.
Platforms
Section titled “Platforms”| Code (vulture-ios) | Change |
|---|---|
Modules/App/Sources/Features/Settings/Settings/Infrastructure/MainSettingsDestination+Controller.swift (.homebase) | Present the new airport picker instead of SelectWaypointViewModel(purpose: .homebase, …) |
Packages/TaskScreens/Sources/TaskScreens/SelectWaypoint/, Hosting/SelectWaypoint/AppWaypointSelection.swift | Keep for .goTo; the home-base purpose leaves |
Packages/Airports/Sources/Airports/AirportManager.swift | A search by code and name, and the nearest list (it has airport(for:) and the haversine) |
Packages/Persistence/Sources/Persistence/HomebaseManager.swift | Unchanged (addOrUpdateHomebase(with:and:)) |
Tests: search by code and by accent-free name; the name format; choosing moves it to the top of the recents. Changelog (“Pick your home base from every airfield”).
Android
Section titled “Android”| Code (vulture-android) | Change |
|---|---|
feature/settings/.../root/SettingsRootScreen.kt, SettingsKey.kt | The home base row in General; the picker as a new settings screen |
feature/settings/.../advanced/AdvancedSettingsSection.kt | The tracking switch |
data/prefs/ (LocalSettings, SyncedSettings.homeBase, model/Places.kt) | The tracking flag; write the home base |
data/sync/ (homebases) | Write the homebases records, not only keep them |
domain/airports | Search and nearest list, as iOS |
Tests and screenshots of both rows and the picker; changelog. Update decisions P9-D3 (the home base row is no longer omitted).
No changes.
- vulture-ios: the airport home base picker; tests; changelog (2026-10-20).
- vulture-android: the tracking switch; the home base row and picker, writing the synced value and records; tests; changelog (2026-10-20).
- vulture-docs: when built, update Home base (Android
done), Privacy and telemetry, Settings overview and P9-D3 in Port decisions; setstatus: shipped.