alexei.dolgolyov
a0d63a3663
Lint & Test / test (push) Successful in 2m1s
- Remove the top-of-file "IMPORTANT: Remove WLED naming throughout the app" checklist. The effort was absorbed by the multi-backend refactor (BLE / USB-serial / ESP-NOW / MQTT / OpenRGB providers all shipped), and the remaining user-facing copy has been swept in separate commits. - Add an "Android Signing Secrets (Gitea)" section covering the four secrets the release APK CI expects, the one-off `keytool` command to generate `release.jks`, the consequences of losing the keystore, and a checklist of the remaining setup steps before tagging v0.4.1.
55 lines
2.8 KiB
Markdown
55 lines
2.8 KiB
Markdown
# TODO
|
|
|
|
## Donation / Open-Source Banner
|
|
|
|
- [x] Add a persistent but dismissible banner or notification in the dashboard UI informing users that the project is open-source and under active development, and that donations are highly appreciated
|
|
- [x] Include a link to the donation page (GitHub Sponsors, Ko-fi, or similar — decide on platform)
|
|
- [x] Remember dismissal in localStorage so it doesn't reappear every session
|
|
- [x] Add i18n keys for the banner text (`en.json`, `ru.json`, `zh.json`)
|
|
- [ ] Configure `DONATE_URL` and `REPO_URL` constants in `donation.ts` once platform is chosen
|
|
|
|
## Android Signing Secrets (Gitea)
|
|
|
|
The CI workflow `build-android.yml` produces a signed release APK **only** when all four secrets below are configured in Gitea → Settings → Secrets. When any one is missing, the "Guard release tag against missing keystore" step hard-fails a `v*` tag build — previously we silently shipped a debug-signed APK labeled as release.
|
|
|
|
| Secret | Contents |
|
|
| --- | --- |
|
|
| `ANDROID_KEYSTORE_BASE64` | Output of `base64 -w0 release.jks` — the whole keystore as one line |
|
|
| `ANDROID_KEYSTORE_PASSWORD` | Keystore password (the `-storepass` passed to `keytool`) |
|
|
| `ANDROID_KEY_ALIAS` | Key alias (e.g. `ledgrab-release`) |
|
|
| `ANDROID_KEY_PASSWORD` | Key password (can be the same as keystore password) |
|
|
|
|
### Generate the keystore (one-time, ~2 min)
|
|
|
|
```bash
|
|
keytool -genkeypair -v \
|
|
-storetype JKS \
|
|
-keystore release.jks \
|
|
-alias ledgrab-release \
|
|
-keyalg RSA -keysize 4096 \
|
|
-validity 9125 \
|
|
-dname "CN=LedGrab, O=Dolgolyov, C=BY"
|
|
|
|
base64 -w0 release.jks > release.jks.b64 # Linux / Git Bash
|
|
# Windows alternative:
|
|
# certutil -encode release.jks release.jks.b64
|
|
# (strip the -----BEGIN/END CERTIFICATE----- header/footer lines)
|
|
```
|
|
|
|
### Critical — back up `release.jks` outside the repo
|
|
|
|
- 1Password attachment, encrypted USB stick, or printed hex + password written down somewhere physical.
|
|
- Losing the keystore = every existing sideloaded install is permanently unable to upgrade. The only workaround is uninstall-then-reinstall, which wipes user data.
|
|
- The `release.jks` file itself must **never** be committed to git. Only the base64 string lives in Gitea secrets.
|
|
|
|
### Why it matters even without Play Store
|
|
|
|
Android's package manager refuses to install an upgrade whose signature differs from the currently-installed APK's signature — enforced by the OS, not Play. So once users install a build signed by key X, every future build they can upgrade to must also be signed by key X.
|
|
|
|
### Current state
|
|
|
|
- [ ] Generate `release.jks` with `keytool` (above) and back it up
|
|
- [ ] Upload the four secrets to Gitea
|
|
- [ ] Tag a throwaway `v0.4.1-test` to verify signed release APK is produced (then delete the tag + release)
|
|
- [ ] Note: any existing `v0.4.0` debug-signed install cannot upgrade to a release-signed v0.4.1 — users must uninstall first
|