The APK names all of com.ubisam.ubgitea as code to compile ahead of
time. The phone does so in the background after installing, and again
after each update; until then the app runs as before.
Agent: main (opus)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The release build type is signed with the key the published builds have had,
so it installs over them.
Agent: main (opus)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- version 0.2.0 (versionCode 2)
- The app reads version.json from the download page once at launch and
offers the page when a newer build is out; settings shows the version
and a check button.
- tools/publish-download.py encrypts an APK under the download password
and writes the page that decrypts it in the browser.
Agent: main (opus)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Gitea's own notification feed doesn't fire for plain pushes (only
issue/PR activity), so this app now periodically checks each favorited
repository's most recent push time itself and posts a local
notification when it advances past what was last seen.
- FavoritePushDetector: pure comparison logic, never notifies on a
repository's first sighting (only a real advance counts), avoiding a
notification storm the first time this feature ever runs.
- GetLatestPushEpochMillisUseCase: extracts the same 'newest branch
commit time' heuristic RepositoryListViewModel already uses for the
repository list's own last-push row, as a shared, reusable use case.
- SharedPreferencesLastSeenPushStore: one long per favorited repo, not
Room (docs/architecture.md reserves Room for offline caching).
- FavoritePushCheckWorker: 15-minute WorkManager periodic job,
network-constrained, no-ops cleanly with no session or no favorites.
- POST_NOTIFICATIONS requested at runtime on API 33+; a denial
degrades safely, the worker still runs and updates its baseline.
No deep link from the notification to the specific repository yet --
tapping it opens the app normally. End-to-end delivery (a real push
landing, 15 minutes elapsing) is unit-tested and the scheduling/
permission wiring is live-confirmed (prompt appeared, was granted, no
crash), but an actual notification firing hasn't been observed within
this same live-testing session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two live-confirmed 403 responses (not source reading, which had already
given one wrong answer) showed /user/starred/{owner}/{repo} requires
BOTH scopes at once: requesting write:repository alone got
required=[write:user]; requesting write:user alone then got
required=[write:repository]. Both are now requested.
Added debug-build-only HTTP status/body logging (HttpTransport
.requireSuccess) and toggleFavorite failure logging, which is how this
was actually diagnosed -- ground truth from the server beats re-reading
Go route source through a summarizing tool. Required testOptions {
unitTests { isReturnDefaultValues = true } } in build.gradle.kts so
those Log calls don't throw inside plain JVM unit tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Login previously left the app entirely for a separate browser task. Now uses
androidx.browser Custom Tabs, which overlays the app's own activity instead of
switching away, and returns automatically on redirect. Deliberately not a
WebView, per RFC 8252: an in-app WebView could read the Gitea login form's
credentials directly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
