DevTools writes devtools_options.yaml into a checkout the first time it runs.
It records which DevTools extensions are enabled on this machine, nothing
about the project, so it differs per checkout and is no use to anyone else.
Ignored rather than committed because under jj, which tracks new files
automatically, being ignored is the only way a file stays out of the next
commit on its own.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The F-Droid listing at apps.randogoth.com declares this app Apache-2.0, and
the repo itself said nothing about its license, so the only statement of it
lived in another repo. Text is apache.org's verbatim, with the appendix's
bracketed copyright placeholder filled in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The shared runner host keeps Gradle daemons alive for up to 3 hours
and hands them to the next matching build regardless of which
project started them. A daemon warmed by an unrelated checkout (even
a local devbox test build) can serve this project's CI run next,
carrying over stale in-memory classpath state and producing
inconsistent "package android.app does not exist" failures.
Disabling the daemon for this one step keeps dependency/wrapper
caches shared while avoiding the live-process contamination.
Flutter caches its JDK location in a per-user global config file
(~/.config/settings), not per-project. On a shared build host that
cross-contaminates between projects: whichever project last ran
without pinning inherits a stale jdk-dir pointing at another
project's (possibly already-gone) build directory, which breaks the
Gradle release build with "JAVA_HOME is set to an invalid directory".
Re-running flutter config --jdk-dir on every devbox shell init keeps
it correct for this project.
Adds a Forgejo Actions workflow that builds a release APK on tag push,
reading signing credentials from repo secrets with a debug-key fallback
for local builds, and publishes the APK plus fastlane changelog to a
Forgejo release.
