c:geo needs a Google Maps API key for maps

What it is, and what it deliberately is not

The README describes c:geo as an open-source, full-featured, always ready-to-go client for geocaching.com, and marks it clearly as unofficial. It also offers basic support for other geocaching platforms, which in practice means the OpenCaching networks rather than a full second implementation.

Two sentences in that paragraph are the product positioning. It does not require a web browser, and it does not require exports. The design assumption is that a user standing in a field with intermittent connectivity opens an app and works, rather than opening a mobile site and hoping.

That shapes what an evaluator should look for. A field tool is judged on whether it works without a network, on how it handles coordinates and logs, and on whether the community-maintained data stays current. None of that is in this README, which is instead dominated by two things: contribution process and build setup.

The licensing is Apache 2.0 with a LICENSE file at the root, and the primary language is Java. The releases are named for their market channel rather than semver, and the recent pattern alternates: `market_20261005` described as a bugfix release on 2026-10-05, then `market_20260923` as a feature release on 2026-09-23, then `market_20260805` as a bugfix release. That is roughly one release a month, alternating in kind, with the last push on 2026-10-16.

Two branches with different jobs

The branch policy is stated unusually precisely, and it is the first thing a contributor needs to understand.

`master` is where new features are developed, and nightly builds are created from it. `release` is where bug fixes to already released features go. The stated rule is that a bug reported against a released version should be fixed on `release` and merged into `master` afterwards, with regular merging from `release` back into `master` recommended to avoid merge conflicts later.

There is a third path for harder bugs: test against `master` first so it lands in nightly builds, while keeping the fix compatible with `release` for later integration. The README points to a wiki page describing that procedure.

This is the branch layout of a project with real users on real devices. It is also the branch layout that will reject a pull request aimed at the wrong branch, so reading it before starting saves a wasted contribution.

The contribution guidance reinforces the same theme. The README asks people to tell them in the issue tracker before hacking on a new feature, and gives the reason plainly: it would be bad to have implemented something great that cannot be included because it does not fit the existing architecture and code. There is a list of good first issues and a query for high priority issues, plus a project page.

The build is standard Android tooling: Android Studio, Gradle, a Jenkinsfile for continuous integration at ci.cgeo.org, plus Codacy and Crowdin badges.

The keys are the actual build friction

Building requires the Android SDK at its latest version including Google APIs at least V26, the Google repository and the Android support repository. On Windows you also need the Google USB Driver to install onto a phone. The IDE setup is documented in the project wiki.

Beyond that, the build needs API keys, and this is where the real configuration work sits.

For Google Maps you need a Maps SDK for Android API key, which the README notes is free and needs no credit card information, though the web form appears to force it. It also warns that you need a Google API-enabled system image for the emulator or device, or Google Maps will not even be offered as a map provider in the app.

For the OpenCaching networks, each supported site has its own OKAPI signup, listed individually: opencaching.de, opencaching.pl, opencaching.ro, opencaching.nl, opencaching.us and opencache.uk. Leaving those blank leaves those networks disabled. geocaching.su keys are generated manually on request to their administration.

Then there is the exception. The README states plainly that the key for Adventure Labs data is not publicly available, so you must leave that entry empty, and you cannot test Adventure Labs in your development builds. That is a feature gap in every locally built c:geo, and it is stated rather than hidden.

How keys reach the build

The key injection is semi-automatic, and the detail that catches people is a caching behaviour.

The documented procedure is: copy `./templates/private.properties` to `./`, edit `private.properties` with your keys, and the file `./main/src/main/res/values/keys.xml` is created on the Gradle build and filled from `private.properties`.

That third step only works if `keys.xml` does not already exist. The README is explicit: when you change your API keys you have to delete the `keys.xml` file. Miss that and you will rebuild with stale keys and conclude your new key is wrong.

There is a manual path too. Copy `./main/templates/keys.xml` into `./main/src/main/res/values/` and edit it by hand. The convention in the template is that each key value is wrapped in `@` characters, so you replace the whole `@...@` sequence with your key, and if a key is missing you remove the value along with the leading and trailing `@`.

Once keys are in place, the build itself is unremarkable. Run `gradlew` from the repository root, which installs the build framework and shows the available build tasks, and start with:

gradlew assembleBasicDebug

Android Studio's Make Project is the documented alternative.

Signing, and the rest of the tree

Producing an installable package needs a signing key, and the README routes that through the IDE: Build, then Generate Signed Bundle and APK, selecting APK, which creates a key store and a project-specific key. The path and access information for those go into `cgeo/private.properties`.

Note the layering of secrets. `private.properties` holds both your third-party API keys and your signing key path, which means one file is the entire credential surface of a build. It is copied from `templates/` rather than committed, which is the right pattern, and it is also the file to keep out of any shared fork.

The repository root shows what else the project carries. There is a `fastlane/` directory for release automation, a `templates/` directory that holds both `private.properties` and the `keys.xml` template, `main/` for the application module, and separate `mapswithme-api/` and `organicmaps-api/` directories. `checkstyle.xml` and `ruleset.xml` with `suppressions.xml` are the Java static analysis configuration, and `test.gwc` is a geocaching test file.

Building a fork is therefore a documented path rather than a reverse-engineering exercise: the README even links a git and GitHub setup page aimed at beginners, along with a wiki page on how to get a bug fix into a release.

Editorial conclusion

Adopt c:geo if you cache geocaches and want a native Android client with offline-friendly field use, rather than a browser. Do not adopt it as an integration platform or a starting codebase without reading the architecture rules the project enforces. Verify first that you have keys for every network you intend to test, that your emulator image includes Google APIs, and that you accept that Adventure Labs cannot be tested in development builds because that key is not publicly available.

Frequently asked questions

Official sources

1. cgeo/cgeo on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases