AirGuard: three detections at changed locations, and a local only claim sitting next to a research opt in

Three sightings at changed locations, or the app stays quiet

The notification rule is stated in one sentence and it has two halves. A tracker has to be detected at least three times, and the locations where it was seen have to have changed. The docs give the reason for the second half in brackets: to make sure it is not your neighbour.

Everything else follows from that. The app scans the phone's surroundings with Bluetooth, and every tracker it finds is saved locally on the device. Detections are compared against each other rather than acted on individually, so a single sighting of a passing tag produces nothing. When both conditions hold, you get a notification.

That design is what backs the promise that the app will never bother you if no one is trying to track you. It also means the tracker has to move with you across recorded locations before anything is said, which is the difference between a car key fob in a car park and something following a person around.

Sound playback is offered for AirTag, not for every Find My device

The description covers AirTags and other Find My accessories, and the detection step treats them the same. The sound feature does not. The docs say that if the tracker is an AirTag you can play a sound to find it, and nothing more general is claimed for the others.

So for an accessory that is not an AirTag, the documented outcome stops at storage, location comparison and the notification. There is no remote trigger, no chirp, no separation between the two device families beyond the identifier the broadcast carries.

The reverse feature is stated plainly: after playing the sound you can view at which locations the device has tracked you. Both halves depend on the same local record of detections, which is also the record the notification is derived from. The trademark note at the end of the file is explicit that AirTag, FindMy and iOS are trademarks of Apple Inc. and that the project is not working together with Apple Inc.

The less than an hour claim has no scan interval attached

The headline promise is that if a device follows you, you get a notification in less than an hour. Nothing in the documentation backs that number. The mechanism section says the app scans periodically and never gives the period, never states how long a location record is kept, and never discusses what Android's background execution limits do to the schedule.

That gap matters because the entire detection rule depends on sampling. Three detections at changed locations is three samples, and how many you get per hour decides whether an hour is plausible, and the file does not say. Battery cost is not mentioned either, and on an Android phone the cost of a Bluetooth scan running continuously is the first question a reviewer asks.

The release cadence gives a partial picture of the work. Three tags are visible, AirGuard 3.1.0 on 2026-06-29, 3.1.1 on 2026-07-20 and 3.1.3 on 2026-09-28, with no 3.1.2 among them, and the newest push on the default branch is dated 2026-09-30, two days after the last release.

Three distribution channels and two different application ids

The app is offered in three places: Google Play, F-Droid, and the GitHub releases of the repository itself. The two store listings do not use the same identifier. The Play link carries the package `de.seemoo.at_tracking_detection.release`, while the F-Droid entry is `de.seemoo.at_tracking_detection`.

The `.release` suffix on the Play build suggests the main tree is the one used for that listing, with a release variant layered on top, which is a common pattern for a project that wants a distinct store build. That is an inference from the identifier rather than something the docs state, and no build type is described anywhere in the file.

Shipping outside the Play store is a deliberate choice for an app about privacy, and it is the only distribution detail the project explains. Nothing is said about signing, update cadence per channel, or whether the GitHub release APK is signed the same way as the store builds.

Local only, except for the part that is offered as optional

The mechanism section ends with a flat guarantee: all of this happens locally on your device, and private information such as location and tracker ids will never leave it. Two paragraphs earlier, under who the project is, it says that in the app you can voluntarily participate in a research study that will share anonymized data with the project.

Those two statements are not necessarily in conflict, since participation is described as voluntary. They do sit close together, and the documentation gives no detail on either side of the boundary. Nothing describes what anonymized data means here, how it is separated from the tracker records described as never leaving the device, what the opt in looks like, or whether it can be withdrawn.

One root level file is worth a reader's attention on this point: `api.properties`. Its contents are not part of the file listing, so what it holds is not visible, and the docs never mention it. Anyone who cares about the local only claim should look at that file directly rather than take the guarantee on the strength of the paragraph.

The repository is set up as a citable research artifact

The project identifies itself as part of the Secure Mobile Networking Lab at the Technical University of Darmstadt in Germany, and states the goal as protecting privacy and finding out how many people are opposed to tracking. The tree matches that framing. There is a `CITATION.cff` at the root, which is citation metadata, and a `privacy-policy/` directory alongside it.

The app also states that it will never be monetized through ads, in-app purchases or anything else, which pairs with the presence of no billing code path described anywhere and with the F-Droid listing.

The build is Gradle, with the wrapper checked in for both platforms including `gradlew.bat`, and a `gradle.properties` at the root next to `build.gradle` and `settings.gradle`. Alongside that sits a `Gemfile` and a `Gemfile.lock`, a Ruby dependency pair, in the root of a Kotlin application whose own build system is Gradle, with a `fastlane/` directory present as well. The listing does not show what the Ruby manifest pulls in or how it is invoked, so its relationship to the release process is not stated.

Editorial conclusion

AirGuard is a small research tool with a clear rule for what counts as following and a local only design that a reader can check against the description. Two things are worth confirming before relying on it. The less than an hour notification claim has no scan interval behind it in the documentation, so treat the timing as unmeasured. And the local only statement and the voluntary study sit in the same file, with a root level api.properties that is not shown, so anyone who does not want data leaving the device needs to check the opt in path and that file before participating. The AirTag only sound playback is a narrower capability than the Find My device wording suggests.

Frequently asked questions

Official sources

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