# j4velin Pedometer for Android: A Hardware-Sensor Step Counter

> j4velin Pedometer is a lightweight Android pedometer written in Kotlin with a Jetpack Compose UI. It uses the device's hardware step-detection sensor instead of GPS or continuous movement tracking, with separate F-Droid and Play flavors.

**j4velin/Pedometer** — Lightweight pedometer app for Android using the hardware step sensor

- Repository: https://github.com/j4velin/Pedometer
- Website: https://play.google.com/store/apps/details?id=de.j4velin.pedometer
- Stars: 1,432 · Forks: 662
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/j4velin-pedometer

## A Narrow, Sensor-First Pedometer

j4velin Pedometer solves a specific problem: counting steps on Android without turning on GPS or recording a person's route. The README describes it as a lightweight pedometer designed to remain available while the hardware step-detection sensor is already running on the referenced Nexus 5. Its scope is intentionally narrower than that of many activity trackers. It counts detected steps, presents step history, and includes Google account features for achievements when the Play flavor is used.

The target audience is Android users who want a basic step counter and who prefer a small, focused application over route mapping or generalized activity tracking. The app does not track movement or location, according to the README. That boundary matters when choosing an app. A user who wants to know which street was walked, how far a trip extended, or whether movement came from walking, running, or transportation should not interpret this project as an alternative to a GPS fitness tracker.

The application is written in Kotlin and uses Jetpack Compose for its user interface. The repository has separate `fdroid` and `play` flavors. The `fdroid` flavor has no Google dependencies, while the `play` flavor adds achievements and leaderboards through Play Games. This split makes the project relevant to users who want a Google-free distribution path and to users who want the Google account integration described in the README.

## How Hardware Step Detection Shapes the Design

The core mechanism is delegation to Android's hardware step-detection sensor. The README states that the app uses the hardware step sensor for minimal battery consumption and does not use GPS. In practical terms, the application can remain focused on the device's step events instead of sampling location continuously. The README makes a strong battery claim for the Nexus 5 setup it describes, saying that the sensor is already running even when no pedometer app is open. That statement is tied to the hardware described in the project documentation and should not be treated as a universal guarantee for every Android device.

The absence of GPS is an architectural choice rather than a missing feature. Since the app does not track movement or location, it does not need to keep a location service active for route recording. The repository does not document sensors beyond the hardware step-detection capability, nor does the README describe accelerometer-based movement classification. That makes the data model and privacy implications easier to understand at a high level, although the documentation does not provide a detailed schema for stored history.

The Google sign-in feature belongs to the `play` path. It is described as a way to unlock achievements and keep the user motivated. The documentation does not state whether steps are uploaded beyond what is required for those Play Games features, so the precise data exchange should be checked in the app's privacy disclosures before adoption. The important distinction is that basic step counting does not require the Google integration, while the `fdroid` build is explicitly described as having no Google dependencies.

## Building the Kotlin and Jetpack Compose App

The repository documents a source build rather than a command-line installer for Android users. An Android user can obtain the app through the linked Google Play listing or the linked F-Droid repository entry. Those are distribution destinations, not repository build commands. For contributors, the build requires the Android SDK with platform 37. The SDK path can be supplied as `sdk.dir` in `local.properties` or through `ANDROID_HOME`.

After the SDK path is configured, the F-Droid debug variant can be assembled with the wrapper. The command below is copied from the README and does not add a Google dependency.

```bash
./gradlew assembleFdroidDebug
```

The README also documents the Play debug variant. It requires `src/play/res/values/games-ids.xml`, which is not part of the repository. That file must contain `app_id` and the achievement and leaderboard IDs exported from the Play Console.

```bash
./gradlew assemblePlayDebug
```

The Gradle wrapper downloads the JDK 21 toolchain by itself when one is not already present, according to the README. This does not remove the need to have the Android SDK available. The resulting source build is therefore most relevant to developers preparing a variant or validating a change, not to someone seeking an APK from a command in the README.

## Running Tests and Lint Across Both Flavors

The repository provides separate unit and Robolectric test tasks for the two flavors. The following command runs the documented `Fdroid` and `Play` debug unit-test tasks:

```bash
./gradlew testFdroidDebugUnitTest testPlayDebugUnitTest
```

The README describes these as unit and Robolectric tests. It does not document integration-test tasks, device-lab instructions, or a required hardware sensor for running the tests, so the test command should not be presented as a complete device-validation procedure.

Lint is also available for both variants:

```bash
./gradlew lintFdroidDebug lintPlayDebug
```

Running both commands covers the flavor-specific source sets that the project defines. The distinction is important because the `play` flavor contains Google-dependent features, while `fdroid` does not. A failure in a Play-specific task does not automatically tell a contributor whether the F-Droid path has the same issue, and vice versa.

The repository layout also includes Gradle wrapper files, `gradle.properties`, `settings.gradle.kts`, and `build.gradle.kts`. Based on that layout, the intended build path is the Gradle wrapper included in the repository. The README does not document supported Android Studio versions, minimum Android API levels, emulator behavior, or CI configuration, so those details should be verified before planning a contribution.

## Release Signing and Version Management

The release instructions define a concrete version-number convention and signing workflow. `versionCode` and `versionName` are maintained in `build.gradle.kts`. The README specifies that the version code is calculated as major multiplied by 1000, plus minor multiplied by 100, plus patch. For version 2.0.0, the expected code is 2000. This is an explicit repository rule, not a general Android requirement.

Release signing requires copying `key.properties.sample` to `key.properties` and pointing it at the release keystore. The repository includes `example.keystore.jks` and the sample properties file, but the release process warns and uses the sample keystore if the required properties or keystore are absent. That fallback is suitable for the documented release check, but it is not a production signing setup. A project-specific first review should therefore check whether the expected private keystore and `key.properties` are present outside the public repository.

The release build command is:

```bash
./gradlew assembleRelease
```

The README says this builds both flavors, applies R8 minification, and writes APKs under `build/outputs/apk/<flavor>/release/`. It also directs the maintainer to install the release APK over the previous version and verify that historical and today's steps remain available. That upgrade check is especially relevant for this project because preserving history is part of the release verification described by the repository.

## The Trade-Off Between Sensor Efficiency and Activity Detail

The main limitation is visible in the product scope. j4velin Pedometer does not track movement or location, so it cannot provide the route-level context associated with GPS-based pedometers. It also does not claim to classify different kinds of movement. Users who need those features should choose a different application category.

Hardware availability is another constraint. The README refers to the hardware step-detection sensor and names the Nexus 5 as the example device. It does not say that every Android device exposes the same sensor, nor does it define behavior for devices without one. Because the documentation is silent on that fallback, an adopter should verify sensor support on the intended handset rather than assume that installation alone guarantees step detection.

The battery claim should also be read narrowly. The README attributes low consumption to using the hardware step sensor and avoiding GPS, with the Nexus 5 used as the stated example. No measured battery figures, test procedure, or device matrix are provided in the repository. That is enough to explain the design goal, but not enough to make a comparative battery claim against another app.

A real alternative is a GPS-based fitness tracker. That approach records location and can support route or distance analysis, but it requires location processing that this project intentionally avoids. Another alternative is a generalized movement-tracking app, which may use motion sensors or location data to classify activity. The practical choice depends on whether the user values a minimal hardware-sensor counter or needs richer activity records.

## Maintenance Signals and Apache-2.0 Use

The repository is not archived, and its last push was on 2026-10-13. The recent release list includes version 2.1.0 on 2026-10-02 and version 2.0.0 on 2026-09-26. Those are concrete signals that the repository has recent development activity, although the documentation does not promise a release schedule or ongoing support for every Android device.

The project is licensed under Apache-2.0. The repository includes `LICENSE` and `NOTICE` files, which are the relevant files for checking the license text and any notices associated with distribution. The license permits use and modification subject to its terms, but this review does not provide legal advice or replace the repository's license files.

The Play flavor adds an operational dependency that the F-Droid flavor does not have. Achievement and leaderboard IDs must be exported from the Play Console and placed in `src/play/res/values/games-ids.xml`. A maintainer or downstream builder without that configuration cannot expect the documented Play Games setup to work. The `fdroid` flavor avoids Google dependencies, so it is the more self-contained build path described by the README.

## Conclusion

Adopt j4velin Pedometer when Android hardware step detection is sufficient and low sensor overhead matters. Do not choose it if you need route tracking, location history, or movement analysis, because the README explicitly says the app does not collect those data. Verify first whether the target device provides the required hardware step sensor, whether history survives an upgrade, and whether the Play Games configuration is needed for achievements and leaderboards.

## FAQ

### How does j4velin Pedometer count steps?

It uses Android's hardware step-detection sensor rather than GPS. The README says the app is designed for low battery consumption and does not track movement or location.

### How do I build the F-Droid version of j4velin Pedometer?

Configure the Android SDK with platform 37 through `local.properties` or `ANDROID_HOME`, then run `./gradlew assembleFdroidDebug`. The `fdroid` flavor has no Google dependencies.

### Does j4velin Pedometer support achievements and leaderboards?

The `play` flavor adds achievements and leaderboards through Play Games. It requires `src/play/res/values/games-ids.xml`, containing `app_id` and the IDs exported from the Play Console.

## Sources

- [j4velin/Pedometer on GitHub](https://github.com/j4velin/Pedometer)
- [License: Apache-2.0](https://github.com/j4velin/Pedometer/blob/master/LICENSE)
- [Project website](https://play.google.com/store/apps/details?id=de.j4velin.pedometer)
- [README](https://github.com/j4velin/Pedometer/blob/master/README.md)
- [Releases](https://github.com/j4velin/Pedometer/releases)

---

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