Find out why the release build breaks.
Servante is a free, open source desktop app for Android and Kotlin developers. Ten tools in one window: signing fingerprints, Compose stability, Gradle versions, SDK disk usage, bundle preflight, Play releases, reminders, an accessibility score, a security assessment and an AI review that runs on your own key.
In developmentThere is no download yet. The first release will be the Signing tool, for macOS, Windows and Linux.
Overview
Fjord Notes, checked 2 minutes ago
Signing
Why does sign-in work in debug and fail in release?
Google Sign-In will fail for Play installs. The Play app signing certificate is not registered in the Firebase project.
| Identity | SHA-256 | Firebase | OAuth client | Play |
|---|---|---|---|---|
| Debug keystore | 3A:91:0C:E4 … 7B:22 | Match | Match | Not used |
| Upload key | C8:5F:A1:09 … D4:6E | Match | Match | Match |
| Play app signing key | F2:77:3D:B0 … 19:AC | Missing | Missing | Match |
- Add the Play signing SHA-1 and SHA-256 to Firebasegoogle-services.json, client app.fjord.notes
- Keystore password committed to the repositoryapp/build.gradle.kts:42
- Upload certificate valid until 2049release.jks, alias upload, RSA 4096
Compose
Why does this composable recompose?
Parameter tags is a List, which the compiler treats as unstable.
Gradle
Which of these versions do not go together?
KSP was built for Kotlin 2.2.10. The build may fail or silently skip processors. Move KSP to a release that matches Kotlin 2.2.20.
| Catalog entry | Current | Latest stable | |
|---|---|---|---|
| ksp | 2.2.10-2.0.2 | 2.2.20-2.0.3 | Required |
| compose-bom | 2026.06.00 | 2026.09.00 | Update |
| okhttp | 5.1.0 | 5.1.0 | Current |
SDK and disk
What is taking all this space?
| Item | Size | Last used | This project |
|---|---|---|---|
| System image, API 33, x86_64 | 6.2 GB | 14 months ago | No AVD uses it |
| NDK 25.2 | 4.1 GB | 9 months ago | Not referenced |
| Gradle 8.7 distribution | 0.4 GB | 11 months ago | Not referenced |
| Build-tools 36.0.0 | 0.2 GB | Today | In use |
Preflight
Will Play accept this build?
app-release.aab, 3.8.0 (412), 18.4 MB
- PassTarget API meets the current Play requirement
- Warn1 of 6 native libraries is not 16 KB alignedlib/arm64-v8a/libsqlcipher.so
- PassNot debuggable, minified, mapping file present
- WarnREAD_MEDIA_IMAGES needs a Play declarationAdded by com.fjord:picker:2.3.0
- PassVersion code 412 is higher than production (409)
Releases
Where is build 412?
Reminders
What deadline is coming?
- 41 daysPlay target API requirementFjord Notes must target the new API level to keep publishing updates
- 67 daysService account key is one year oldRotate the key used for the Play connection
- 23 yearsUpload certificate expiresNothing to do
Notifications are local. Servante has no server to send them from.
Accessibility
Can someone using TalkBack or large text use this screen?
- 9 icon buttons have no label for screen readersNoteRow.kt:64, IconButton without contentDescription WCAG 4.1.2
- Secondary text on surface is 3.4:1 in dark theme, 4.5:1 neededColor.kt:22, onSurfaceVariant on surface WCAG 1.4.3
- Tag chips are 32 dp tall, below the 48 dp touch targetTagChip.kt:18 Android target size
- All text sizes use sp and survive 200% font scale38 composables checked
Security
What would a pentester flag in the first hour?
2 critical, 3 warnings, 14 checks passed
A summary of automated checks, not a certification.
- API key hard-coded in sourceSyncClient.kt:17, value sk_l…9f2a MASVS-STORAGE-1 CWE-798
- Session token stored in plain SharedPreferencesSessionStore.kt:31 MASVS-STORAGE-1 CWE-312
- Exported activity accepts any deep link without verificationAndroidManifest.xml:48, ShareActivity MASVS-PLATFORM-1
- 1 dependency has a known vulnerabilitycom.fjord:picker:2.3.0, fixed in 2.3.4 OSV
- No cleartext traffic, release build minified, backups restrictedmanifest and network security config
AI review
Review the architecture of the app module
To the provider you chose, with your own API key, which stays in your system keychain. Three files are excluded because they look like secrets.
About 41,000 tokens
This is an interactive preview with fictional data, not a recording of the app. Click the tools in the sidebar. The real app is being built in the open.
Ten tools, each built around one question
Android Studio is good at writing code. These are the questions it leaves you to answer with a terminal, three browser tabs and a forum thread.
Why does sign-in work in debug and fail in release?
Reads your keystores and signing configs, computes every SHA-1 and SHA-256, and compares them with what Firebase and Play expect. It names the fingerprint that is missing and where to add it.
Why does this composable recompose?
Runs the Compose compiler reports for you and makes them readable: which parameters are unstable, why, and the fix as a diff. The answer comes from the compiler, not from a guess.
Which of these versions do not go together?
Checks Gradle, AGP, Kotlin, KSP, Compose and the JDK against each other, lists the updates in your version catalog, and reviews the build properties that cost you time.
What is taking all this space?
System images, emulators, NDKs, Gradle caches, old wrapper distributions. See what the open project needs, what nothing uses, and move the rest to the trash.
Will Play accept this build?
Drop an AAB or APK. Target API, 16 KB page size alignment, permissions and which library added them, exported components, size by category. Compare two builds side by side.
Where is build 412?
Your Play tracks in one view: internal, closed, open and production, with version codes and staged rollout progress. It uses your own service account.
What deadline is coming?
Local notifications before the Play target API deadline, before a certificate runs out and when a service account key gets old. Plus a log of everything Servante changed for you.
Can someone using TalkBack or large text use this screen?
A score out of 100 from rules over your Compose and XML code: missing labels, small touch targets, contrast computed from your real theme, text that breaks at large sizes. Each finding names its WCAG criterion.
What would a pentester flag in the first hour?
Hard-coded secrets, plain-text token storage, exported components, weak crypto, risky WebView settings and vulnerable dependencies. Findings map to OWASP MASVS, and the grade says clearly that it is not a certification.
What would a senior reviewer say about this project?
An optional deeper review of architecture, build setup, accessibility, security or release readiness, run with your own API key or a local model. Findings point at real files and lines.
AI when you ask for it, on your key
Every tool works without AI. The review is an extra pass you start yourself.
- You see the payload firstPick the modules and files. The preview is exactly what gets sent, with an estimate of the size before anything leaves.
- Secrets are left outKeystores, local.properties, google-services.json and anything that looks like a key are excluded automatically.
- Answers are checked against your sourceA finding that points at a file or line that does not exist is dropped. Fixes are shown as diffs and never applied on their own.
- Or keep it on your machinePoint Servante at a local model and nothing leaves at all.
Built for a tool that sits next to your signing keys
It reads by default
Anything that changes a file, deletes something or installs something asks first, with a summary of what will change. Every change is written to a local log.
Nothing is made up
When Servante cannot read something, it says "Unavailable" and why. You never get a placeholder where real data should be.
No account, no server, no telemetry
Requests go to Google with your credentials and to the AI provider you picked, when you ask. The app lists every destination it can contact.
Open source, free, for good
Apache 2.0. No paid tier and no license key. You can read the code that touches your keystore, and build it yourself.
Where the project stands
Tools ship one at a time, in this order. The full task list is in the roadmap.
- Signing keystores, fingerprints, Firebase and Play comparisonNext up
- Compose compiler reports, rules, graph, scorePlanned
- Gradle compatibility, catalog updates, propertiesPlanned
- SDK and disk inventory and cleanupPlanned
- Preflight AAB and APK checksPlanned
- Releases and reminders Play tracks, deadlinesPlanned
- Accessibility and security score, grade, WCAG and MASVS mappingPlanned
- AI review bring your own key, local modelsPlanned
- Command line the same checks in CIPlanned
Questions
Can I download it today?
No. Servante is in development and nothing has been released yet. The demo on this page is a preview with fictional data. Watch the repository on GitHub to hear about the first release.
What will it cost?
Nothing. Servante is open source under Apache 2.0, with no paid tier. AI review uses your own provider account, so you pay that provider for what you use, or nothing with a local model.
Which systems will it run on?
macOS, Windows and Linux. It is written in Kotlin with Compose Multiplatform for Desktop.
What will leave my computer?
Requests to Google APIs with your own credentials for the Play features, version lookups against Maven repositories, package names and versions to OSV.dev when you ask for a vulnerability check, an optional update check on GitHub, and the files you choose when you start an AI review. There is no Servante server.
Will it change my project or my keystores?
Only when you ask. It reads by default. Any change is confirmed first with a summary, then recorded in a local log. Keystore passwords are used once and never stored.
Do I need an AI key?
No. The nine other tools run locally with their own rules. A key is only needed for the AI review, and a local model through Ollama needs none.
How is this related to Sindri?
Sindri is a Mac app by Walid Sassi that does this job for iOS and macOS developers, and it inspired Servante. The two projects are separate. A servante is the French word for the rolling tool cabinet in a mechanic's workshop.
Can I help?
Yes. The roadmap lists every task, and Compose and Gradle rules are a good place to start. Open an issue on GitHub before a large change.
Follow the build
Star or watch the repository to get the first release when it lands.