Files
flamenet-messenger-android/client/build.gradle.kts
T
Paul HittandClaude Opus 4.8 a40cc2d2d4 Measure Android coverage, and round-trip the vault
JaCoCo was not configured on either JVM module, so the Android numbers
were unknown rather than good. :engine and :client are plain Kotlin/JVM
precisely so they can be measured without an emulator; now they are.
Baseline: engine 84.9% lines, client 47.3%.

Vault was the outlier in engine at 53%, and its uncovered half was almost
entirely save/load pairs — credentials, trust pins, the delivery key, the
key-log pins, the roster, avatars, per-line deletion.

That is not an arbitrary gap. It is the exact shape of a bug that has
already shipped in this app twice. `requireKeyLog` was computed, held in
memory and never written down, so a security control the UI offered
silently reverted on every relaunch. `Trust.changed` says the same thing
in its own doc comment: returned by `record()`, persisted by nothing, so
`state()` could never answer CHANGED, the "Accept new keys" button could
never render, and a contact who reinstalled became permanently
unmessageable while the header insisted nothing had changed.

Neither was hard to write. Both were invisible because a save and a load
that disagree still compile and only differ after a restart, which no
test performed. Every test here writes with one Vault and reads with a
second built over the same bytes, because that is the only arrangement in
which the two halves are forced to agree.

Includes the AAD binding the class doc promises: a trust record copied
into another contact's slot must not open, or someone with file access
could attribute a stranger's keys to someone you trust.

Vault 53.0% -> 84.9% lines, engine 84.9% -> 92.3%.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-30 09:13:26 -04:00

51 lines
1.6 KiB
Kotlin

// The relay transport.
//
// Plain Kotlin/JVM like `:engine`, and for the same reason: HTTP against a
// relay has nothing to do with Android, and keeping it off the platform means
// its tests run against a real local server on any machine, with no emulator.
// OkHttp works identically on both.
plugins {
kotlin("jvm")
jacoco
}
repositories { mavenCentral() }
dependencies {
api(project(":engine"))
implementation("com.squareup.okhttp3:okhttp:4.12.0")
compileOnly("org.json:json:20240303")
testImplementation(kotlin("test"))
testImplementation("org.json:json:20240303")
// A real HTTP server, so the tests exercise headers, status codes and
// bodies rather than a hand-written fake that agrees with the client about
// everything including its mistakes.
testImplementation("com.squareup.okhttp3:mockwebserver:4.12.0")
}
kotlin {
compilerOptions {
jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_17)
}
}
java {
sourceCompatibility = JavaVersion.VERSION_17
targetCompatibility = JavaVersion.VERSION_17
}
tasks.test {
useJUnitPlatform()
testLogging { events("passed", "failed", "skipped") }
}
// Coverage for this module. `:engine` and `:client` are plain JVM libraries
// precisely so they can be measured and tested without an emulator, so there is
// no reason for their numbers to be a guess.
tasks.withType<Test>().configureEach { finalizedBy(tasks.named("jacocoTestReport")) }
tasks.named<JacocoReport>("jacocoTestReport") {
dependsOn(tasks.named("test"))
reports { xml.required.set(true); html.required.set(true) }
}