# The Android identity samples show Credential Manager, a passkey Shrine and a credential provider > Google's android/identity-samples repository is a set of Android Studio projects rather than a library: a minimal Credential Manager app, a fuller Shrine app demonstrating recommended sign-in UX, a Wear companion, a credential provider implementation, a legacy SMS verification sample and WebView integration. It is Apache 2.0 licensed and Kotlin throughout. **android/identity-samples** — Multiple samples showing the best practices in identity on Android. - Repository: https://github.com/android/identity-samples - Stars: 519 · Forks: 282 - Language: Kotlin - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/android-identity-samples ## What is in the repository: six sample apps, not a library This repository contains a set of individual Android Studio projects to help you get started writing or understanding Android identity features. That framing is the important one, because it sets expectations about what you can and cannot take from it. There is no published artefact, no dependency you add to a build file, and no API you call. What you get is working projects you open in Android Studio, read, and copy from. The top level entries confirm the shape: CredentialManager/, CredentialProvider/, DigitalCredentials/, Shrine/, SmsVerification/ and WebView/ directories, alongside a CODEOWNERS file, a CONTRIBUTING.md, the Apache 2.0 LICENSE and the README. The DigitalCredentials/ directory is present in the tree but is not described in the README's sample list, which covers the other five. That mismatch is worth noting if you are browsing the repository rather than reading the readme, since it tells you the set of samples is still moving. The primary language is Kotlin, and the last push was on 2026-10-09 with the repository not archived, so the samples are being kept current against the platform's identity APIs. The repository is hosted under the android GitHub organisation, which is Google's own account for Android platform code rather than a third party. That matters for trust in a sample about authentication: the samples come from the platform vendor rather than from a community contribution of unknown provenance. ## The two branches serve different purposes There are two main branches, main and credman_codelab, and the distinction is worth understanding before you clone anything. The main branch contains the primary samples for Credential Manager. The credman_codelab branch contains the starting codebase for the Credential Manager Codelab, which the README links to as a hosted workshop on codelabs.developers.google.com. A codelab starting codebase is deliberately incomplete in a specific way, because the point of the workshop is for you to fill in the gaps. So the two branches answer different questions. main shows finished, working implementations you can read end to end. credman_codelab gives you a skeleton with a tutorial attached. If you want to understand what correct Credential Manager code looks like, main is what you want. If you want to be walked through building it, the codelab branch plus the hosted guide is the path. That distinction is not stated as prominently as it could be, since the branch names do not signal it, so it is worth reading the README's branch section before picking one. The default branch is main, so a plain clone gives you the finished samples, which is the right default for most readers. ## CredentialManager and Shrine: minimum example against recommended UX The two main samples on main are deliberately different in ambition, and reading them in that order is the most useful way to learn the API. CredentialManager is a simple app demonstrating how to use basic Credential Manager functions. That is the minimal surface: get a credential provider, ask it for a credential, and handle what comes back. If you want to know which classes and which calls exist, this is where to look. Shrine is a more developed mobile app featuring best practices and recommended UX when using Credential Manager. The sample features multiple methods of sign-up, sign-in, settings configuration, and session management. Four features in one sample, and the list is the point: it is telling you that Credential Manager is not only about one login button, but about the whole shape of an account system, including how the user signs up as well as how they sign in. Settings configuration and session management are the two that are easiest to get wrong in a real application. A passkey-backed account still needs a way for the user to see and manage their credentials, and it still needs the application to know whether there is an active session, and neither of those is answered by the credential provider API itself. So the division of labour is sensible: CredentialManager shows the API calls, Shrine shows what a real application does around them. Reading both is a reasonable way to build a mental model, and reading only Shrine risks copying complexity you do not yet need. ## The other four samples each cover one specific surface The remaining samples are narrower, and each one covers a surface where Credential Manager has to work alongside something else. Shrine/wear is a Wear app that works together with the Shrine mobile app, and it features seamless authentication via passkey, password, and Sign-in-with-Google logins. Three methods, on a wearable, coordinated with the phone. The interesting part is the coordination: the watch and the phone are different clients with different capabilities, and the sample shows how a sign-in that starts on one ends on the other. CredentialProvider/MyVault is a simple credential provider app implementation. This is the other side of the API from the client samples. A credential provider is the app that actually holds and manages credentials, and the fact that the repository includes one tells you the samples are not only about calling into the system but about implementing the system. SmsVerification is a legacy sample using Play Service's SMS Verification APIs. The word legacy is the signal, and it is the one sample here that is explicitly about an approach the platform has moved on from. It is still useful to read for the mechanics of phone number verification, but you should not treat it as current guidance. WebView contains 2 folders, and the split between them is instructive. CredentialManagerWebView contains code snippets to use Credential Manager with WebView, while WebkitWebView contains a sample app that uses the Webkit library to implement passkey creation in WebView. The distinction is between the general case and the specific one. Credential Manager inside a WebView is the awkward case, because the WebView has its own origin and the credential manager's origin rules do not always line up. The Webkit library exists specifically for building web content into Android apps, which is presumably why the sample uses it for passkey creation in WebView. ## Where this repository is the wrong tool The first limit is that a sample is not production code, however good it is. These projects exist to teach, which means they optimise for being read rather than for being deployed. You will not find a dependency injection graph, an error reporting pipeline, a feature flag system, or a state machine for the credential lifecycle, because none of those teach Credential Manager. Copying the sample into your application is a starting point, not a finish. The second limit is the moving target. These samples track a platform API that changed substantially in a short period, with passkeys and the Credential Manager API arriving and displacing the older approaches. The SmsVerification sample is the visible evidence of that history: it is in the repository as a legacy sample, and the sample set around it has been reorganised to reflect the current API. Expect this repository to keep changing as the platform does, and expect the branch structure to shift with it. The third limit is scope. There is no coverage of federation, no server-side counterpart, and no samples for the DigitalCredentials/ directory that the tree contains but the README does not describe. If you are building a passkey relying party with a credential provider, the client-side samples cover half the problem and you will be reading the platform documentation for the rest. The alternative to weigh is the official documentation and API reference. Those are authoritative on behaviour and are kept current with the platform, while these samples are authoritative on style and recommended UX. The samples have the advantage that the code is complete enough to run, so you can see the flow rather than infer it from prose. There is also a third option worth naming: reading how other production apps do it. An open source application that ships passkey sign-in for real users will show you how the API behaves under failure conditions, retries and account linking, which is where samples usually stop. The samples tell you the happy path in a form you can trust; a real application tells you what happens next. One practical caution. Copying an authentication sample means copying its security decisions along with it, including whichever token handling and key storage approach the sample uses. Check that the sample's choices about local credential storage match what your threat model requires before adopting them. ## Maintenance, licence and how to read these samples well The maintenance picture is current. The last push was on 2026-10-09 and the repository is not archived, so the samples are being updated. The repository has no GitHub releases, which is expected for a collection of sample projects rather than a distributed artefact, and the samples are versioned by branch rather than by tag. The licence is Apache-2.0, recorded in the repository listing with a LICENSE file at the root. That is a permissive grant with an express patent clause and it is the licence most Google sample code uses, so copying code from these projects into a commercial application carries no copyleft obligation. That is a licensing note rather than legal advice, and the point about a patent clause is that it is more protective than MIT for the same permissiveness. The CODEOWNERS file is worth noticing for a different reason. It identifies who owns each area of the repository, which is how a sample set stays coherent as the platform changes: there is a named owner for the Credential Manager samples, one for the Wear app, one for the provider, and so on. It also tells you where to send a question about a specific sample, which is more useful than the generic issues tracker. There is also a CONTRIBUTING.md, which for a repository in the android organisation normally means external contributions are routed through a Google-owned process rather than accepted directly. If you want to fix a sample, the first step is to read that file rather than opening a pull request. On how to read the samples well: start with CredentialManager for the API shape, then Shrine for the surrounding application structure, then the narrow samples for the platform surfaces you need. That order goes from the smallest thing that compiles to the most complete picture, and it avoids the trap of starting with the Wear sample and reverse engineering the whole model from the most complex example in the set. The one thing worth doing before you write any of it is to check the current platform documentation against what the samples do. The samples are maintained against a moving API, and the gap between what the platform does now and what the sample was last updated to demonstrate is exactly the kind of detail that costs an afternoon when you assume the sample is current. ## Conclusion Adopt this repository as a reference when you are building sign-in with Credential Manager or passkeys on Android and want to see the recommended UX rather than the API surface alone. Do not adopt it as a dependency, since it is a collection of sample apps with no published artefact, and note that the two branches serve different purposes, with main holding the samples and credman_codelab holding codelab starting code. Verify first which branch matches your task, and that the Wear and WebView samples are relevant to the platform surfaces you actually ship. ## FAQ ### What is in the android/identity-samples repository? A set of Android Studio projects showing Android identity best practices: a simple CredentialManager app, the more developed Shrine app with recommended sign-in UX, a Shrine Wear companion app, a CredentialProvider/MyVault credential provider implementation, a legacy SmsVerification sample, and a WebView directory with two separate samples. ### What is the difference between the main and credman_codelab branches? The main branch contains the primary Credential Manager samples, while the credman_codelab branch contains the starting codebase for the Credential Manager Codelab hosted on codelabs.developers.google.com. The default branch is main. ### What does the Shrine sample demonstrate? Shrine is a more developed mobile app featuring best practices and recommended UX when using Credential Manager, with multiple methods of sign-up and sign-in, settings configuration and session management. There is also a Shrine/wear Wear app that works together with it, featuring authentication via passkey, password and Sign-in-with-Google. ### What are the two samples in the WebView directory? CredentialManagerWebView contains code snippets to use Credential Manager with WebView, and WebkitWebView contains a sample app that uses the Webkit library to implement passkey creation in WebView. ### What licence is the Android identity samples released under? Apache-2.0, with a LICENSE file at the repository root. The primary language is Kotlin, the repository has no GitHub releases, and the last push was on 2026-10-09 with the repository not archived. ## Sources - [android/identity-samples on GitHub](https://github.com/android/identity-samples) - [Issues](https://github.com/android/identity-samples/issues) - [License: Apache-2.0](https://github.com/android/identity-samples/blob/main/LICENSE) - [README](https://github.com/android/identity-samples/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/android-identity-samples