# Vela Maps publishes a per-action table of what reaches Google, and routes are computed by OSRM with Google supplying only the traffic

> An Android maps and navigation client with no Play Services, drawing open vector tiles through MapLibre and Jetpack Compose, aimed at GrapheneOS and other degoogled ROMs. The interesting part is not the tile source but the honesty: every action that touches Google is enumerated, and one setting reduces the answer to nothing.

**PimpinPumpkin/Vela** — Degoogled maps & turn-by-turn navigation for Android - MapLibre + Jetpack Compose, no Google Play Services

- Repository: https://github.com/PimpinPumpkin/Vela
- Website: https://pimpinpumpkin.github.io/Vela/
- Stars: 1,100 · Forks: 47
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/pimpinpumpkin-vela

## The project publishes a table of what reaches Google, action by action

Most privacy claims on map apps are one sentence at the top of a page. Vela's is a table with a row per user action, and the first half of it is reassuring enough to be worth reading closely.

Panning, zooming, and browsing the map reaches nothing. Tiles come from OpenFreeMap, with streets and labels from OpenStreetMap. The places drawn on the map also reach nothing by default, because they are open data baked into tiles in the project's own repository: Overture Maps and AllThePlaces, positioned with OpenStreetMap coordinates, streamed from the releases. Dropping a pin or tapping a house number reaches nothing either, because OpenStreetMap's Nominatim service names the spot.

The last row is the strongest. Everything you save reaches nothing, ever. There is no account, no Vela backend, and no Vela telemetry, and saved places, history, and settings stay on the phone.

So the default posture is that browsing a map touches nobody, which is a much stronger claim than most apps make and is achieved by not being a wrapper at all. The project states that explicitly: it is a native Android application drawing open vector tiles through Jetpack Compose and MapLibre, with no Google SDK, no Play Services, and no API key.

It also states why it looks familiar. The basemap uses Google's own sampled colours and Google Sans Flex labels. The resemblance is the point; the underneath is not.

## Traffic is the one thing Google still answers for, and you can switch it off

Asking for directions is the row where the table gets interesting, and the answer is the traffic and only the traffic.

The route itself is computed by the open OSRM router, or computed on the phone from an OsmAnd-format region file when you have downloaded the region. Google's own routing is used only as a fallback when the open router is down, which is the correct priority order: your route works even if Google refuses to answer.

On top of that open route, Google is asked anonymously for the live estimated time of arrival. This is the concession, and the documentation is precise about its cost. The request repeats every couple of minutes while you drive, and Settings, then Navigation, turns it off.

Walking is handled separately and more sparingly. For a walk, Google is asked once for its route, and that route is used only when it is substantially shorter than the open one. So a walk does not generate the periodic polling that a drive does.

Transit is its own row with its own fallback chain. Departure boards come from Transitous for the stops Vela draws from open transit data. Where Transitous has no coverage, Vela falls back to the stop's Google page, which is a narrower and more defensible use of the fallback than substituting Google's data wholesale.

The overall shape is worth naming: the open stack computes geometry, the proprietary stack supplies freshness. That is a reasonable division of labour for map software, and Vela is explicit that it does not pretend the second half is optional, since live traffic is the one feature the open stack genuinely does not have.

## Typing a search sends Google's autocomplete every time you pause

This row is the one to read before installing, and it is the most revealing line in the table.

Typing sends Google's own autocomplete each time you pause. Submitting sends a Google search. The text is described as going anonymously, like a logged-out browser with no account, which is true of the request payload and not of the timing pattern. A request that fires on every pause in your typing carries the rhythm of what you are writing, which is a weaker signal than the words themselves and is exactly the kind of thing that distinguishes a person from a script.

There is a partial mitigation in the same row: text that starts with a house number also goes to the open Photon geocoder. So the one query type that has a good open equivalent is doubled up rather than sent only to Google.

Tapping a place is the other row that reaches Google, described as an anonymous lookup of that place with no account and no app key, returning hours, reviews, and photos. The documentation names the reason plainly: those are the things only Google does well. Settings, then Places, stops the lookup for places tapped on the map.

So the picture is complete and it is not flattering in the way most privacy pages are. Map browsing is entirely local to open data. Routing is open except for traffic freshness. Search leaks typing rhythm. Place details leak the fact that you looked at a place. Each of those is separately controllable, and none of them is hidden.

## Use Vela without Google makes the answer nothing at all

There is a setting whose stated effect is that the answer becomes nothing at all, and it is worth understanding how that is achieved without gutting the app.

Downloading a region is what makes it possible. Once you have one, the map, search, routing, and turn-by-turn navigation all keep working with no network at all. That is the mechanism behind the offline claim, and it works because the tile pipeline and the routing input are both local files, not live services.

The privacy setting does the same thing while you still have a connection. Under Settings, then Privacy, then Use Vela without Google, the answer to what reaches Google becomes nothing, which means the search autocomplete, the place lookups, and the traffic ETAs are all suppressed.

What you give up is the part that could not be replicated locally, and the documentation is candid that something remains even in the full-open configuration. A few capabilities need a real browser engine, and the first page of a place's reviews is named as an example. Those are read from a Google page in an offscreen WebView, anonymously, and the project keeps a list of them under a heading in its privacy document.

That admission is the one to weigh. An offscreen WebView loading a Google page is a real network request that the nothing rows in that table do not cover, and the fact that it is enumerated in a separate document rather than hidden in a row is the correct handling. If that particular request is unacceptable to you, the setting that suppresses everything is the answer.

## One signing key across every channel, and the app cert is not the repo fingerprint

The distribution section addresses a problem that most sideloaded Android projects leave open, which is how a user tells whether the APK in their downloads folder is the one the author built.

The answer is a published certificate fingerprint. Every Vela APK, from any channel, is signed with the same key, and that key's SHA-256 certificate fingerprint is printed in the README. The check on a desktop machine is one command:

```bash
apksigner verify --print-certs vela-maps-*.apk
```

On the phone, the project points at a third-party verifier application that checks the same thing, with a specific formatting requirement: the package name goes on the first line and the fingerprint on the second, so you paste the block rather than the single line above it.

```
app.vela
29:93:8B:48:58:06:3E:42:E6:77:FF:95:C9:01:CD:48:24:8A:7F:03:2A:3A:E8:5F:9B:9E:56:17:56:8B:0D:36
```

Then it makes the distinction that matters and that most projects get wrong. This fingerprint is the certificate the app is signed with and it stays the same across releases. It is not a checksum of any particular APK, since an APK's content changes every build. And it is explicitly not the F-Droid repository fingerprint documented elsewhere, because that one signs the repository index rather than the app.

Conflating those two would let someone verify an index and conclude the app inside it was verified too. Separating them is the difference between a signature check and a formality.

Android also enforces part of this for you: after the first install, an update signed with a different key is refused. So a build that installs over your existing Vela provably came from the same source as the one you already trusted.

## Three release channels, and the beta warning applies unevenly to them

Vela ships on a weekly stable channel, a nightly channel, and a canary channel, and the three are described with different stability.

The recommended route for most people is the weekly stable, which Obtainium tracks automatically. Turning on include prereleases in Obtainium instead gives you the nightly channel. The tags make the distinction visible in their names, with the release titles reading nightly or canary rather than a plain version.

For F-Droid users the badge points at the project's own repository rather than the central catalogue, and the documentation says so explicitly rather than borrowing a badge that implies catalogue presence. Adding the repository URL to any F-Droid client serves the same signed APKs, weekly stable by default. The same artefacts are also available directly from the releases page.

The beta warning sits near the top of the README and says the project may run into bugs, with an issue template linked for reporting them. It then adds the qualifier that matters for anyone choosing a channel: nightlies and canary builds are newer still and less tested than the weekly stable. That is a slightly odd thing for a canary channel to admit, since the usual understanding is that a canary exists to catch problems early, but it accurately sets expectations for a project that has not yet declared itself stable.

The repository is GPL-3.0 licensed, not archived, and was pushed to on 1 October 2026, so the tree is moving quickly. Release cadence matches: three tagged builds across the last three days.

## Osmand-format regions, a baseline profile, and a D-pad test suite

A few things in the repository tree explain what kind of application this is more clearly than the feature list does.

There is a directory named for a shaded copy of OsmAnd. That is the offline region format: rather than inventing a proprietary tile package, Vela consumes the region files that another open navigation project already produces, which means users can reuse regions they may already have.

There is a baseline profile directory. Android uses baseline profiles to know which code paths matter at startup, and shipping one is a sign the developers profile the app rather than assuming.

There is a D-pad test suite. A navigation app that claims turn-by-turn is expected to work on a car head unit, and head units are driven with a directional pad rather than a touchscreen. Testing that is a different discipline from testing a phone, and the presence of a dedicated suite suggests the automotive case was a design constraint rather than an afterthought.

Alongside those, the tree holds a separate core module, a scripts directory, a tools directory, a site directory for the published documentation, an F-Droid packaging directory, and two signed calibration files, one of them carrying its own signature. The documentation surface is unusually large for a project of this size: a specification, a privacy document, a features document, a roadmap, a security policy, a build guide, a translation guide, a frequently asked questions page, and a book, all published as a searchable site alongside a one-page tour.

The project also borrows a comparison from a better-known degoogling effort, describing itself as what NewPipe is to YouTube but for Google Maps, which is a claim about intent rather than about features.

## Conclusion

Vela Maps fits someone on a degoogled ROM who still wants turn-by-turn navigation with real traffic, and who would rather know exactly which requests leave the phone than trust a privacy toggle. That per-action table is the reason to read the documentation before installing anything. Two things to check first. That you understand the default is not zero: typing a query sends Google's autocomplete on every pause, which is a keystroke-timing signal, and tapping a place does an anonymous Google lookup unless you turn that off in Settings. Second, which channel you install. The project is in beta and says so, with weekly stable, nightly, and canary builds of decreasing stability, so start on the weekly channel and verify the signing certificate before your first install, since that fingerprint is the only thing standing between you and a repackaged APK that Android will accept on first run.

## FAQ

### What is Vela Maps?

It is a degoogled maps and turn-by-turn navigation client for Android, built with Jetpack Compose and MapLibre with no Google Play Services, no Google SDK, and no API key. The README compares it to what NewPipe is to YouTube but for Google Maps, and it is built to run on GrapheneOS and other no-GMS ROMs.

### Does Vela Maps send anything to Google while I browse the map?

Nothing by default. Panning and zooming reach nothing, with tiles from OpenFreeMap and streets and labels from OpenStreetMap, and the places on the map come from Overture Maps and AllThePlaces positioned with OpenStreetMap and baked into tiles in the repository. Everything you save also reaches nothing, with no account, no backend, and no telemetry.

### When does Vela Maps ask Google for routing?

Only for live traffic. The route itself is computed by the open OSRM router or on the phone from an OsmAnd-format region file, and Google's route is used only if the open router is down. Google is asked anonymously for the traffic ETA on top, which repeats every couple of minutes while driving and can be turned off under Settings, Navigation.

### Can I use Vela Maps without any network connection?

Yes. Download a region and the map, search, routing, and turn-by-turn navigation keep working with no network. Settings, Privacy, then Use Vela without Google achieves the same result while you still have a connection, suppressing search, place lookups, and traffic requests.

### How do I verify a Vela APK is genuine?

Every Vela APK from any channel is signed with the same key, and its SHA-256 certificate fingerprint is published in the README. Run `apksigner verify --print-certs vela-maps-*.apk`, or use the App Verifier project with the package name on the first line and the fingerprint on the second. Note this is the app certificate, not the F-Droid repository fingerprint.

### Which Vela release channel should I install?

The weekly stable. Obtainium tracks it automatically, and turning on include prereleases gives the nightly channel instead. The project is in beta, and its own warning notes that nightlies and canary builds are newer and less tested than the weekly stable.

## Sources

- [License: GPL-3.0](https://github.com/PimpinPumpkin/Vela/blob/main/LICENSE)
- [PimpinPumpkin/Vela on GitHub](https://github.com/PimpinPumpkin/Vela)
- [Project website](https://pimpinpumpkin.github.io/Vela/)
- [README](https://github.com/PimpinPumpkin/Vela/blob/main/README.md)
- [Releases](https://github.com/PimpinPumpkin/Vela/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pimpinpumpkin-vela