android/security-samples: Google's reference implementations for Play Integrity, biometrics and DirectBoot

A directory of worked examples, not a package you depend on

The android/security-samples repository describes itself as multiple samples showing the best practices in security APIs on Android. The word that matters is samples. There is no library to add to your build, no published artifact and no version to pin, because the repository has no GitHub releases at all. What it has is a set of directories, each holding a small application that shows one integration end to end.

The top level of the tree gives you the map: `PlayIntegrityAPI/`, `AndroidDeveloperVerificationAPKSigningExample/`, `BiometricLoginKotlin/`, a `BiometricAuthentication/` directory, `DirectBoot/`, plus `CONTRIBUTING.md`, a `LICENSE` and a `.github/` folder. The project is written in Kotlin and licensed under Apache-2.0, which matters if you intend to copy code rather than to link against it.

That distinction sets expectations. A sample is useful when you are learning the shape of an integration, because it shows the sequence of steps in the order they need to happen. It is not useful as a dependency, because there is nothing to depend on and no release train to upgrade with. The last push to the repository was on 2026-08-07, so the code is moving, but it is moving as examples, not as a supported artifact.

Play Integrity: a client, a server and the Play Console

The Play Integrity API sample is the most operationally complete piece in the repository. It demonstrates a client and server setup, and it provides step by step instructions for configuring the Google Play Console for testing. The stated intention is that the sample be followed as an end to end demonstration of the integration process, and it includes three different micro-apps that reflect critical use cases.

The three app structure is the interesting design choice. Rather than one example with one flow, the sample isolates several distinct situations so that you can find the one that matches your situation, which is closer to how an integrity decision is actually made in production, where the verdict handling differs by case.

The Play Console configuration is not optional garnish in this sample. The instructions for configuring the console for testing are part of the deliverable, which tells you that the API cannot be exercised from a local build alone. The app, the server and the console settings are one system, and the sample is arranged to be walked through in that order. There is no API key, endpoint or console setting spelled out in the repository index, so the specifics live in the sample directory itself and in the Google Play Console.

The adi-registration.properties file and your developer snippet

The Android Developer Verification APK Signing example is the narrowest of the samples and the most concrete. It shows exactly which file to create, `adi-registration.properties`, and provides the folder structure needed to guide you. The purpose is twofold: to check the placement of the file, and to ensure the correct insertion of your unique developer snippet for successful verification.

That framing is worth reading carefully. The sample is a placement and formatting guide, not a feature demo. A registration file has to sit at a specific path with specific keys, and the failure mode when it is wrong is a verification that does not succeed, so the sample's job is to remove guesswork about where things go. The developer snippet is per developer, which is why the example cannot ship a working value for you.

The lesson this sample teaches is narrow but easy to get wrong in a larger codebase: some security configuration is a file location contract rather than an API call, and the contract is undocumented enough that copying a known good folder structure is the practical approach.

BiometricLogin as the canonical integration shape

The BiometricLogin sample is described in the repository index as the canonical sample demonstrating how to integrate Android Biometrics into apps. The index also says which kinds of application it is meant for, and it names a wide spread: government, healthcare, financial, enterprise, or general usage. That list is the project's own argument for reading it, since it claims to be the reference implementation rather than one option among several.

The sample lives in `BiometricLoginKotlin/`, and the tree also holds a `BiometricAuthentication/` directory. The index text does not describe what that second directory contains, so its role is not something the repository's own documentation settles, and it is worth looking at it directly rather than assuming it duplicates the Kotlin sample.

What makes biometric integration worth a reference implementation at all is the sequence rather than the API call. A biometric prompt is easy to call and easy to get wrong, because the decisions around availability, fallback, and enrolment state are where applications diverge. Reading a worked shape for that flow is the reason this sample is here, and the fact that the index calls it canonical is the reason to start there rather than in a blog post.

DirectBoot and the storage that exists before unlock

The DirectBoot sample demonstrates how to store and access data in device protected storage that is always available while the device is booted. The distinction it is teaching is between credential protected storage, which only becomes readable after the user unlocks, and device protected storage, which is available earlier in the boot sequence.

The practical relevance is limited but real. An application that must do something before unlock, such as servicing a background synchronisation or presenting a state that does not depend on the user's credential, runs into the fact that the ordinary app data directory is not there yet. The sample exists to show the correct storage area for that case.

It is worth being precise about the boundary of the claim. The sample demonstrates storing and accessing data in that storage area; it does not claim to solve every pre unlock problem, and the index does not describe how the storage is encrypted, how it interacts with a credential set up flow, or what happens on a device with no screen lock. Those are questions for the sample's own code and for the platform documentation, and the repository index does not answer them.

The deprecation notice inside the repository's own index

The repository index contains a warning that most visitors skim past. It states that the samples below it have been deprecated, are no longer maintained, and will be deleted in March 2026, and it points readers to the developer.android.com samples page for other samples that may be of interest.

Read literally, that notice is a claim about a set of samples in the index, and the exact membership of that set is not spelled out, so treat it as a reason to check before you copy. It also means the deletion date has already passed relative to the last push on 2026-08-07, which is either a deadline that was not met or a notice that has gone stale, and neither possibility makes the affected samples a safe starting point for a new integration without looking.

The practical reading is that the durable part of this repository is the set of samples still present, and the destination named in the notice, developer.android.com/samples, is where the platform's own sample catalogue lives. A team that wants reference implementations with a stated support posture should check that catalogue, since it is a maintained publishing surface, rather than relying on a directory list in a repository whose own index warns about parts of itself.

What to copy, and what to write yourself

The honest use case for this repository is reference reading. The samples are the shape an integration should take, produced by the platform's own team, which is why they are worth studying even when you will not copy a line. The Play Integrity sample in particular encodes a workflow that spans a client, a server and console configuration, and that kind of sequence documentation is hard to reconstruct from API references.

The limit is equally clear. A sample demonstrates a path through an API, usually the happy path, in a context someone else chose. Your application has a different data model, a different threat model and a different error surface, and none of those are parameterised. Copying a sample's structure and calling it a design is where security samples go wrong, because the sample quietly assumes a trust boundary it cannot enforce for you.

The most defensible workflow is to read the sample to learn the required order of operations, the file locations the platform expects, and the console or manifest obligations, then write your own implementation against the current platform documentation. Treat the sample as a map of the integration, not as the integration. And check the deprecation notice before you start, because parts of this index are marked for removal.

Editorial conclusion

Adopt these samples as the starting point for an Android security integration when you want Google's own reference shape for the Play Integrity API, biometric login or device protected storage, and you are willing to treat each directory as a worked example rather than a maintained library. Do not adopt anything from this repository as a dependency, since it publishes no releases and no library artifact, and do not assume the biometric or DirectBoot entries are current, because the index carries a notice that some samples are deprecated, no longer maintained and slated for deletion in March 2026. Verify first which sample directories still match the API you are integrating, and check the last push, which was on 2026-08-07, against your own release timeline before copying a configuration file into a shipping app.

Frequently asked questions

Official sources

1. android/security-samples on GitHub
2. Issues
3. License: Apache-2.0
4. README