Follow the sibling project's rename to dev-updater

It is no longer "local" -- it serves over WireGuard rather than the LAN --
and it is specifically for developing new apps. Renaming the references
here at the same time keeps one name to search for across both repos.

Also drops the last references to gen-dev-cert.sh, which the in-process
certificate generation replaced: the build script and the Gradle task now
say to start the server once, and test-wg-tunnel.sh reads the
certificates from the XDG directory rather than the repo.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw
This commit is contained in:
irisandClaude Fable 5 committed 2026-08-25 05:10:20 -04:00
1 parent 65743b899d
commit 56491f84b0
12 files changed
+42 -41

No files matched your search

+3 -3
View File
@@ -6,7 +6,7 @@ plugins {
// The CA this app pins is baked in at build time from the certificates on
// the machine doing the build -- `$XDG_CONFIG_HOME/ai-app/certs/ca.pem`,
// as written by ../gen-dev-cert.sh. AI_APP_CA overrides the path.
// which the server generates on first start. AI_APP_CA overrides the path.
//
// Reading it rather than keeping a pasted copy in the source is what makes
// the trust boundary follow the build: an APK built on the backend host
@@ -45,8 +45,8 @@ abstract class GeneratePinnedCert : DefaultTask() {
if (!ca.isFile) {
throw GradleException(
"No CA certificate at $path.\n" +
"Run ./gen-dev-cert.sh on this machine first -- the app pins the CA it " +
"generates, and the certificate has to exist before an APK can embed it.\n" +
"Start ai-server once on this machine first -- it generates the CA the " +
"app pins, and the certificate has to exist before an APK can embed it.\n" +
"Set AI_APP_CA=/path/to/ca.pem to build against a different one.",
)
}
+1 -1
View File
@@ -6,7 +6,7 @@
network address, including a plain socket to a LAN IP literal.
Without it the traffic is silently dropped, surfacing only as a
connect timeout. See MainActivity.kt's runtime request, and
local-updater's manifest for the full story. -->
dev-updater's manifest for the full story. -->
<uses-permission android:name="android.permission.ACCESS_LOCAL_NETWORK" />
<application
@@ -36,7 +36,7 @@ class MainActivity : ComponentActivity() {
// Transparent status bar on every version; the Surface below paints
// through underneath it and content insets itself. Same reasoning
// as local-updater's MainActivity.
// as dev-updater's MainActivity.
enableEdgeToEdge()
WindowCompat.getInsetsController(window, window.decorView).isAppearanceLightStatusBars = true
@@ -36,7 +36,7 @@ import kotlinx.coroutines.launch
import kotlinx.coroutines.withContext
// Status colors, keyed by the wire strings in Events.kt. Light theme only,
// as in local-updater.
// as in dev-updater.
private val AWAITING_COLOR = Color(0xFFB26A00)
private val RUNNING_COLOR = Color(0xFF2E7D32)
+9 -8
View File
@@ -1,16 +1,17 @@
#!/bin/sh
# Builds the app's APK, ready to install on a phone through Local Updater.
# Builds the app's APK, ready to install on a phone through Dev Updater.
#
# ./build-apk.sh
#
# The APK pins the CA on *this* machine ($XDG_CONFIG_HOME/ai-app/certs/ca.pem,
# or AI_APP_CA), so build it on the machine that runs the backend: an app
# built somewhere else trusts a CA that backend can't present, and simply
# won't connect. Run ../gen-dev-cert.sh first if there are no certificates
# yet; the build stops with that instruction if it can't find one.
# won't connect. Start ai-server once first if there are no certificates
# yet -- it generates them; the build stops with that instruction if it
# can't find one.
#
# Unlike ./run-android.sh, this touches no emulator: it only produces the
# file. Installing on a real phone goes through Local Updater, which serves
# file. Installing on a real phone goes through Dev Updater, which serves
# whatever is under this project's build directory.
set -eu
@@ -41,7 +42,7 @@ CA="${AI_APP_CA:-${XDG_CONFIG_HOME:-$HOME/.config}/ai-app/certs/ca.pem}"
if [ -f "$CA" ]; then
# Printed so a wrong or stale certificate is visible here rather than as
# a handshake failure on the phone. Compare with the server's own
# ca-sha256.txt, which gen-dev-cert.sh writes beside it.
# the CA the server is actually presenting.
FINGERPRINT=$(openssl x509 -in "$CA" -pubkey -noout 2>/dev/null \
| openssl pkey -pubin -outform der 2>/dev/null \
| openssl dgst -sha256 -binary 2>/dev/null \
@@ -49,8 +50,8 @@ if [ -f "$CA" ]; then
echo "==> Pinning the CA at $CA"
echo " fingerprint: $FINGERPRINT"
else
echo "No CA certificate at $CA -- run ../gen-dev-cert.sh on this machine" >&2
echo "first, or set AI_APP_CA to one. The APK has to embed it at build time." >&2
echo "No CA certificate at $CA -- start ai-server once on this machine" >&2
echo "(it generates them), or set AI_APP_CA. The APK embeds it at build time." >&2
exit 1
fi
@@ -62,7 +63,7 @@ echo
echo "==> Built $APK"
[ -f "$APK" ] && ls -lh "$APK" | awk '{print " " $5}'
echo
echo "To get it onto the phone: add this project to Local Updater (or hit"
echo "To get it onto the phone: add this project to Dev Updater (or hit"
echo "Update on it if it's already there) and install from there."
echo "Then start the backend and scan the enrollment QR it prints:"
echo " ./server/target/release/ai-server --rotate-token"
+1 -1
View File
@@ -1,6 +1,6 @@
#!/bin/sh
# Builds and runs this app on an emulator, creating/booting the AVD first if
# it isn't already up. Same flow as local-updater's run-android.sh; see that
# it isn't already up. Same flow as dev-updater's run-android.sh; see that
# script for the reasoning behind the avd handling.
#
# Environment setup (SDK location, PATH, ...) lives in ./android-env.sh,