Skip to content

Android Solid Services

Single sign-in to Solid for Android. One app holds the user's pod accounts. Every other app on the device reaches those pods through it — with the user's permission, and without ever handling a credential.

For your app, that is one dependency and no authentication code at all.

  • Quickstart

    Sign a user in and write to their pod, in about ten minutes.

  • Client or API?

    The one decision to make up front. Takes a minute.

  • Build with it

    Contacts, sharing, resources, notifications — one page each.

  • Install the app

    For people who just want Solid on their phone.

The problem

Solid gives people their own data. But on Android, every app that wants to use a pod has to become an identity client in its own right: run the OIDC flow, mint and rotate DPoP tokens, store them safely — and then the next app does all of it again.

The user signs in separately in each app. Each app's mistakes with those credentials are its own to make.

How this solves it

Android Solid Services owns the login. Tokens are DPoP-bound to keys generated in the Android Keystore, encrypted at rest, and they never leave the app. Other apps talk to it over AIDL and get results, never credentials.

The user signs in once, grants each app access explicitly, and can revoke it at any time.

// The whole of your authentication code.
val authorize = registerForActivityResult(AuthorizeWithSolid()) { result ->
    if (result is SolidSignInResult.Authorized) onSignedIn(result.webId)
}

What you get

Several accounts at once

Accounts from different pod providers, all signed in, all usable. Every call names the WebID it is for, so routing is explicit.

No dangerous permissions

Sign-in launches from your own activity, so nothing needs overlay or contacts permissions. Solid accounts appear in Android Settings like any other.

Sharing that pods understand

View / Add / Edit access over Web Access Control or Access Control Policy, share links, and a Linked Data Notifications inbox for offers and requests.

Data modules, not just bytes

Contacts and tickets as standard RDF, laid out so other Solid apps read the same data.

See it in action

Tap any screen to enlarge it.

Sign in Signed in Accounts Granted apps
Choosing a pod provider, or entering a custom pod server URL The signed-in WebID and the storages it advertises Two Solid accounts signed in at once, one marked active An app's grant, with a button to revoke it
Any Solid provider, or your own server The WebID and its storages Several accounts, all live at once Every grant, revocable

The pieces

Component Role Published
Android Solid Services The app that holds the accounts and exposes the IPC services GitHub Releases
client For apps that go through Android Solid Services Maven Central
api For apps that talk to pods directly Maven Central

There is also a sample app that runs every SDK call against a live pod, each shown beside the code that made it — the fastest way to watch a call behave before you write it.

The client sample app with all five IPC services bound, listing its demonstrations

The sample app, bound to all five services and ready to run its catalogue against a live pod.

New to Solid?

Solid is an open standard, led by Sir Tim Berners-Lee, that puts people in control of their own data. Instead of living inside an app's servers, your data lives in a pod you own. Apps ask for permission to read or write it, and you can withdraw that permission at any time.

The result is that data and applications come apart: you can switch apps without losing anything, and two apps can use the same data without copying it between them.

Questions, bugs, contributions

Please open an issue — including compatibility reports against a particular pod server, which have led to several fixes. Contributing covers building from source.

Acknowledgments

Funded by NLnet.