Sky Map: an open-source Android astronomy app with a modern v2 rewrite

What Sky Map solves on Android

Sky Map is an Android astronomy application for people who want to explore the night sky from a phone. Its historical identity matters because the project began as Google Sky Map, launched for the first Android phone at Searchology in 2009. Google stopped active support in 2011, and the original developers subsequently open-sourced the application with permission. The repository now describes Sky Map as a community application, with the former developers continuing work under their own resources and without Google branding.

The project targets ordinary Android users rather than a narrow professional astronomy audience. The README presents it as free, open-source, ad-free, and without tracking or data sales. Those are product claims made by the project documentation, not an independent audit, but they explain the intended difference from an advertising-supported sky viewer. The Play Store page and F-Droid listing provide distribution routes for people who do not want to build an APK themselves.

Sky Map has also become a preservation and modernization project. The repository keeps the old application in `stardroid-v1/` and places the current rewrite in `stardroid-v2/`. This split is important for anyone evaluating maintenance. The README says the v1 codebase has been retired and that contributions are currently closed. The v2 application is presented as a complete rewrite and a more modern Android foundation, but the README does not provide a detailed feature inventory for that rewrite.

How the repository separates Sky Map v1 and v2

The repository layout exposes two distinct application generations rather than one continuously upgraded source tree. `stardroid-v1/` is the legacy application, while `stardroid-v2/` is the current rewrite. The README says v2 is a complete rewrite designed to look more like a modern Android app and to provide a platform for new features. That is the clearest architectural fact available from the project documentation. It does not publish a detailed diagram of rendering, sensor handling, data sources, or internal module boundaries for v2.

The older generation retains an architecture rooted in the original Google Sky Map codebase. Its history explains why the interface can appear dated even though much of the code has been rewritten since the Google period. The README also retains the internal name `stardroid` in identifiers, even though the product is now called Sky Map. For developers, that means the application name and package identifiers should not be treated as interchangeable.

This structure creates a clear adoption decision. A user can install the current app without caring which source directory produced the package. A maintainer or contributor must first determine whether the target is the retired v1 application or the active v2 rewrite. The README does not document a migration path from v1 source changes into v2, so compatibility between the two implementations should not be assumed.

Installing Sky Map and completing a first launch

The project does not provide a command-line installation procedure in the README. It points users to Google Play and F-Droid instead. For an Android user, the first real step is to obtain the app from one of those listings and install the package on a compatible Android device. The documentation does not state a minimum Android version, required permissions, sensor requirements, or offline behaviour, so those details must be checked on the relevant store listing and in the application itself.

On the Play Store route, search for the package identifier shown in the README and confirm that the listing is `com.google.android.stardroid`. On the F-Droid route, the README links to the package at `f-droid.org/en/packages/com.google.android.stardroid/`. These links are useful because they distinguish the current published application from the similarly named historical Google product.

The README does not give a documented first-use tutorial, such as a calibration sequence, pointing procedure, or settings checklist. It does specifically direct users to `help.md` and `troubleshooting.md` for accuracy issues and for the reason compass calibration may not behave as expected. That is the most concrete first-use guidance in the repository. Do not infer that a successful store installation guarantees accurate compass alignment or a particular sensor setup.

Building from source is also not a first-use path for most people. Although the repository contains Android application directories and a Travis CI badge, the README's contribution instructions are crossed out and state that contributions are closed while v1 is retired. The visible documentation does not give verified local build commands, so inventing a local build tutorial would go beyond what the README confirms.

Recent v2 releases and maintenance boundaries

The repository is not archived, and its last push was on 2026-10-14. The recent release list includes `v2.1.4` on 2026-10-13, `v2.1.3` on 2026-10-12, and `v2.1.2` on 2026-09-30. These dates indicate recent activity around the v2 line. They do not tell you which Android devices, Play Store tracks, or release variants received each build, because the release listing contains only version names and dates.

The README states that the same former Google developers continue to maintain the project. It also describes the work as being done in spare time by a couple of former Googlers in Pittsburgh. That statement sets a reasonable expectation about the project's operating model. It should not be interpreted as a promise of a particular response time for issues or a guaranteed release cadence.

Upgrade cost is higher for contributors than for app users. V1 is retired, its contribution instructions are marked as no longer active, and the project asks people to watch for ways to contribute in v2 once it is more settled. Existing v1 modifications therefore do not have a documented forward path. V2 users face the usual app-update process, but the README does not describe migration of saved settings, locations, observations, or user data between versions.

Licensing rules that affect forks and derivative apps

Sky Map has a split licensing structure, and the repository's custom licence terms matter more than a single licence label suggests. The README identifies `stardroid-v1/` as Apache License 2.0 and `stardroid-v2/` as GPLv3. It also says that the combined work is distributed under GPLv3 and that forks, modifications, and derivative versions of the combined codebase must be completely open-sourced under GPLv3.

The v2 module has an additional permission under GPLv3 section 7 for distribution through app stores. The README points to `stardroid-v2/LICENSE.md` for the full terms and `stardroid-v2/NOTICE.md` for Apache-2.0 provenance. Those files, rather than a badge or a short README summary, are the appropriate documents for a distribution review.

There is a separate restriction on brand identity assets. Launcher and notification icons, onboarding artwork, and similar identity marks are reserved under the terms described in the README. For `stardroid-v2/`, the authoritative list is the `[arr]` section of `stardroid-v2/ASSET-LICENSES.txt`. The documentation says these assets may not be used, duplicated, or modified in a third-party fork or distribution without express written consent. A fork can therefore face different conditions for code and for visual identity. This is a licensing boundary, not legal advice, and the relevant files should be checked before publishing a branded derivative.

Why Sky Map is not the right choice for every Android codebase

The clearest limitation is the project's split between a retired v1 application and a newer rewrite whose internal architecture is not documented in the README. A developer who needs to patch the existing v1 code cannot rely on the repository's old contribution route, because the project explicitly says that v1 has been retired and contributions would be wasted. A developer who wants to build a new astronomy product may also find that the v2 feature set and extension points are not sufficiently documented there.

Sky Map is also a particular kind of project to adopt as a dependency. The README presents it as a complete Android application, not as a reusable astronomy library with a documented public API. There is no confirmed information there about a stable SDK, embedding interface, headless rendering service, or automation API. Treating the app repository as a general astronomy component would therefore be an unsupported assumption.

A practical alternative is to choose a different project when the requirement is a documented library, unrestricted reuse of visual assets, or an actively open contribution workflow. Those are different needs, not worse versions of Sky Map. Sky Map remains a reasonable choice when the requirement is an end-user Android sky application distributed through the listed stores, with the repository's own licence and branding boundaries accepted.

Editorial conclusion

Sky Map suits Android users who want a free, ad-free astronomy app and are comfortable accepting its current distribution model. It is less suitable for developers seeking an actively contribution-friendly v1 codebase or unrestricted reuse of the launcher and onboarding artwork. Before adopting or forking it, check the specific module licence, especially `stardroid-v2/LICENSE.md`, `stardroid-v2/ASSET-LICENSES.txt`, and the retired status of `stardroid-v1/`.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sky-map-team/stardroid on GitHub