aiko/denpa

Fork 0

Get an Android phone attached with the APK installed on it #48

New issue

Closed

opened 2026-07-30 13:15:05 +00:00 by aiko · 3 comments

aiko commented

2026-07-30 13:15:05 +00:00

Owner

Question

No phone has ever been attached to this project. STATE.md records the intent —
the human attaches a phone with USB debugging enabled, then the orchestrator
drives adb — and it was never done; only the OnePlus Pad has run anything.

The phone is one of the three surfaces the destination names, so nothing can
prove v1 without it, and several decisions on this map are easier to make with a
real small screen in hand rather than a breakpoint in a spec.

Nothing to decide here. The work:

Attach a phone, USB debugging enabled.
Build and install the debug APK on it (an Android build starts cold).
Grant SYSTEM_ALERT_WINDOW and RECORD_AUDIO.
Screenshot what it currently looks like at phone width.

Record on resolution: the device model and Android version, the screenshots, and
anything that failed on the way — those are facts later tickets depend on.

denpa#23, denpa#34, denpa#12

Map: aiko/denpa#41

## Question No phone has ever been attached to this project. STATE.md records the intent — the human attaches a phone with USB debugging enabled, then the orchestrator drives `adb` — and it was never done; only the OnePlus Pad has run anything. The phone is one of the three surfaces the destination names, so nothing can prove v1 without it, and several decisions on this map are easier to make with a real small screen in hand rather than a breakpoint in a spec. Nothing to decide here. The work: - Attach a phone, USB debugging enabled. - Build and install the debug APK on it (an Android build starts **cold**). - Grant `SYSTEM_ALERT_WINDOW` and `RECORD_AUDIO`. - Screenshot what it currently looks like at phone width. Record on resolution: the device model and Android version, the screenshots, and anything that failed on the way — those are facts later tickets depend on. ## Related - `denpa#23`, `denpa#34`, `denpa#12` --- Map: `aiko/denpa#41`

aiko added the

wayfinder:ticket

wayfinder:task

labels

2026-07-30 13:15:05 +00:00

aiko self-assigned this

2026-07-30 13:53:52 +00:00

aiko commented

2026-07-30 13:53:52 +00:00

Author

Owner

Both devices are attached. Facts for the tickets downstream of this one:

	Phone	Tablet
Model	Pixel 7 Pro (`cheetah`)	OnePlus Pad (`OPD2203`)
Serial	`28171FDH30025T`	`GUMZLZ9DAMXSGYDY`
Android	17 (SDK 37)	16 (SDK 36)
ABI	`arm64-v8a`	`arm64-v8a`

Both are arm64-v8a, so the ort Android prebuilt covers both — no armv7 or x86_64 leg is needed for real hardware. See #44.

The APK on disk is stale. app-universal-debug.apk was built 11:16 today; C3 merged at 12:01 and the rename at 14:53, so it predates #28, #29, #32 and the whole rename. Any launcher-label check against it would be wrong. Rebuilding from main at f796efa.

Toolchain blocker recorded for #35, not for today. The only NDK installed is 27.2.12479018. ort's Android prebuilts are built against r28, and the maintainer is explicit that "NDK 27 definitely won't work" — it fails at runtime with a dlopen libc++ symbol error, not at build time, which is the worst way for it to fail. Installing NDK r28 is a prerequisite for #35, not for the current app.

Android 17 / SDK 37 on the phone is newer than anything the #44 research covered (it went up to Android 15 on the foreground-service rules). The FGS restrictions have tightened at every release since 14, so #47's overlay decision and #35's microphone service should be checked against 17 specifically rather than assumed.

**Both devices are attached.** Facts for the tickets downstream of this one: | | Phone | Tablet | |---|---|---| | Model | Pixel 7 Pro (`cheetah`) | OnePlus Pad (`OPD2203`) | | Serial | `28171FDH30025T` | `GUMZLZ9DAMXSGYDY` | | Android | 17 (SDK 37) | 16 (SDK 36) | | ABI | `arm64-v8a` | `arm64-v8a` | **Both are `arm64-v8a`**, so the `ort` Android prebuilt covers both — no armv7 or x86_64 leg is needed for real hardware. See [#44](https://git.aiko.works/aiko/denpa/issues/44). **The APK on disk is stale.** `app-universal-debug.apk` was built 11:16 today; C3 merged at 12:01 and the rename at 14:53, so it predates `#28`, `#29`, `#32` and the whole rename. Any launcher-label check against it would be wrong. Rebuilding from `main` at `f796efa`. **Toolchain blocker recorded for `#35`, not for today.** The only NDK installed is **27.2.12479018**. `ort`'s Android prebuilts are built against **r28**, and the maintainer is explicit that *"NDK 27 definitely won't work"* — it fails at runtime with a `dlopen` libc++ symbol error, not at build time, which is the worst way for it to fail. Installing NDK r28 is a prerequisite for `#35`, not for the current app. **Android 17 / SDK 37 on the phone is newer than anything the `#44` research covered** (it went up to Android 15 on the foreground-service rules). The FGS restrictions have tightened at every release since 14, so `#47`'s overlay decision and `#35`'s microphone service should be checked against 17 specifically rather than assumed.

aiko commented

2026-07-30 14:02:11 +00:00

Author

Owner

Built, installed and launched on the phone. Fresh universal debug APK from main at f796efa, built 15:56 (the APK previously on disk was from 11:16 — it predated C3 and the whole rename). Installed on both devices, Success on each. Screenshot at .denpa-work/shots/phone.png.

denpa#25's Android acceptance box is now observed rather than asserted. aapt2 dump badging reports application-label:'Denpa', and the launcher resolves works.aiko.ollvt.debug/works.aiko.ollvt.MainActivity on both devices — so the display name changed and the bundle identifier did not, exactly as #25 claimed. That was one of the two boxes closed on trust; it is now closed on evidence.

What the phone actually shows

The app launches, takes focus (mCurrentFocus=works.aiko.ollvt.debug/works.aiko.ollvt.MainActivity) and renders. Three things are wrong, reported as observed, not diagnosed — this is one screenshot at one viewport, not a root cause:

It does not fill the screen. On a 1440×3120 display the content occupies a column roughly 870×1780 px, top-aligned, horizontally centred, with the remainder black. It reads like the webview laying out at a viewport that is not the device's.
The station bar renders twice. 周波数集音姿重ねて表示 · ANDROID のみ開局 appears at the top of the content column and again lower down the screen.
No safe-area inset at the top. The app's own bar sits underneath the system status bar, so the clock and status icons overlap its left end.

What is right: the empty state is the 受信記録 one — 「まだ何も受信していない」, the carrier meter glyph, and a 同調をはじめる button. Sensible, since no go-between is running.

This is material for #46 (what one unified log looks like at phone width) — it now has a real device to be wrong on, rather than a breakpoint in a spec. Note that #12's mobile chrome and #16's viewport dispatch were both verified against a browser at a resized window, never against a phone.

Still outstanding on this ticket

The tablet is locked (mDreamingLockscreen=true), so it has the new APK installed but has not been launched or captured. Needs a human to unlock it.
SYSTEM_ALERT_WINDOW was not granted and is no longer needed for v1 — #47 ruled the overlay out.
RECORD_AUDIO not yet granted; nothing requests it until #35.

**Built, installed and launched on the phone.** Fresh universal debug APK from `main` at `f796efa`, built 15:56 (the APK previously on disk was from 11:16 — it predated C3 and the whole rename). Installed on both devices, `Success` on each. Screenshot at `.denpa-work/shots/phone.png`. **`denpa#25`'s Android acceptance box is now observed rather than asserted.** `aapt2 dump badging` reports `application-label:'Denpa'`, and the launcher resolves `works.aiko.ollvt.debug/works.aiko.ollvt.MainActivity` on both devices — so the display name changed and the bundle identifier did not, exactly as `#25` claimed. That was one of the two boxes closed on trust; it is now closed on evidence. ## What the phone actually shows The app launches, takes focus (`mCurrentFocus=works.aiko.ollvt.debug/works.aiko.ollvt.MainActivity`) and renders. Three things are wrong, reported as **observed, not diagnosed** — this is one screenshot at one viewport, not a root cause: 1. **It does not fill the screen.** On a 1440×3120 display the content occupies a column roughly 870×1780 px, top-aligned, horizontally centred, with the remainder black. It reads like the webview laying out at a viewport that is not the device's. 2. **The station bar renders twice.** `周波数集音姿重ねて表示 · ANDROID のみ開局` appears at the top of the content column and again lower down the screen. 3. **No safe-area inset at the top.** The app's own bar sits underneath the system status bar, so the clock and status icons overlap its left end. What is right: the empty state is the 受信記録 one — 「まだ何も受信していない」, the carrier meter glyph, and a 同調をはじめる button. Sensible, since no go-between is running. This is material for [#46](https://git.aiko.works/aiko/denpa/issues/46) (what one unified log looks like at phone width) — it now has a real device to be wrong on, rather than a breakpoint in a spec. **Note that `#12`'s mobile chrome and `#16`'s viewport dispatch were both verified against a browser at a resized window, never against a phone.** ## Still outstanding on this ticket - **The tablet is locked** (`mDreamingLockscreen=true`), so it has the new APK installed but has not been launched or captured. Needs a human to unlock it. - `SYSTEM_ALERT_WINDOW` was not granted and is no longer needed for v1 — [#47](https://git.aiko.works/aiko/denpa/issues/47) ruled the overlay out. - `RECORD_AUDIO` not yet granted; nothing requests it until `#35`.

aiko commented

2026-07-30 14:10:58 +00:00

Author

Owner

Resolution

Done. Both devices are attached, both run the current build, and both have been launched and
captured.

	Phone	Tablet
Model	Pixel 7 Pro (`cheetah`)	OnePlus Pad (`OPD2203`)
Serial	`28171FDH30025T`	`GUMZLZ9DAMXSGYDY`
Android	17 (SDK 37)	16 (SDK 36)
Screen	1440x3120, density 476	2000x2800, density 400
ABI	`arm64-v8a`	`arm64-v8a`

Screenshots: .denpa-work/shots/phone3.png (portrait), .denpa-work/shots/phone2.png
(landscape), .denpa-work/shots/tablet.png.

Facts later tickets depend on

Both devices are arm64-v8a, so ort's single Android prebuilt covers both and no armv7
or x86_64 leg is needed for real hardware. See #44.
The x86_64 emulator is unusable for anything touching ort, so device testing is not
optional once #35 starts.
The only NDK installed is 27.2.12479018. ort's Android prebuilts target r28, and the
maintainer is explicit that r27 does not work — it fails at runtime with a dlopen libc++
symbol error, not at build time. Installing NDK r28 is a prerequisite for #35.
The phone runs Android 17 (SDK 37), newer than any source #44 could reach. Foreground
service rules have tightened at every release since 14, so #35's microphone service should be
checked against 17 rather than against the Android 15 behaviour on record.
The APK that was on disk was stale — built 11:16, while C3 merged at 12:01 and the rename at
14:53. Rebuilt from main at f796efa; both devices now run that.

`denpa#25`'s Android acceptance box is now observed

aapt2 dump badging reports application-label:'Denpa', and the launcher resolves
works.aiko.ollvt.debug/works.aiko.ollvt.MainActivity on both devices. The display name changed
and the bundle identifier did not, exactly as #25 claimed. That box was closed on trust; it is
now closed on evidence.

What the devices showed

Filed as #49: onboarding renders as a fixed
292x600 CSS px card, so it is a small box in a large black screen — ~60% of the phone's width
and ~37% of the tablet's. Plus no safe-area inset, so the rail sits under the system status bar.
The rest of the chrome does not have this problem; onboarding is the outlier.

One correction worth recording, since it nearly became a finding: an apparent duplicate step
rail in two screenshots was an artifact of the downscaled renders being read, not of the
devices. A row-luminance profile of the full-resolution captures shows a single rail on both —
content bands at the top (status bar, rail, headline), the meter, the CTA, and the system gesture
pill, with nothing between. Measured, not eyeballed.

## Resolution **Done.** Both devices are attached, both run the current build, and both have been launched and captured. | | Phone | Tablet | |---|---|---| | Model | Pixel 7 Pro (`cheetah`) | OnePlus Pad (`OPD2203`) | | Serial | `28171FDH30025T` | `GUMZLZ9DAMXSGYDY` | | Android | 17 (SDK 37) | 16 (SDK 36) | | Screen | 1440x3120, density 476 | 2000x2800, density 400 | | ABI | `arm64-v8a` | `arm64-v8a` | Screenshots: `.denpa-work/shots/phone3.png` (portrait), `.denpa-work/shots/phone2.png` (landscape), `.denpa-work/shots/tablet.png`. ### Facts later tickets depend on - **Both devices are `arm64-v8a`**, so `ort`'s single Android prebuilt covers both and no armv7 or x86_64 leg is needed for real hardware. See [#44](https://git.aiko.works/aiko/denpa/issues/44). - **The x86_64 emulator is unusable for anything touching `ort`**, so device testing is not optional once `#35` starts. - **The only NDK installed is 27.2.12479018.** `ort`'s Android prebuilts target **r28**, and the maintainer is explicit that r27 does not work — it fails at *runtime* with a `dlopen` libc++ symbol error, not at build time. **Installing NDK r28 is a prerequisite for `#35`.** - **The phone runs Android 17 (SDK 37)**, newer than any source `#44` could reach. Foreground service rules have tightened at every release since 14, so `#35`'s microphone service should be checked against 17 rather than against the Android 15 behaviour on record. - **The APK that was on disk was stale** — built 11:16, while C3 merged at 12:01 and the rename at 14:53. Rebuilt from `main` at `f796efa`; both devices now run that. ### `denpa#25`'s Android acceptance box is now observed `aapt2 dump badging` reports `application-label:'Denpa'`, and the launcher resolves `works.aiko.ollvt.debug/works.aiko.ollvt.MainActivity` on both devices. The display name changed and the bundle identifier did not, exactly as `#25` claimed. That box was closed on trust; it is now closed on evidence. ### What the devices showed Filed as [#49](https://git.aiko.works/aiko/denpa/issues/49): **onboarding renders as a fixed 292x600 CSS px card**, so it is a small box in a large black screen — ~60% of the phone's width and ~37% of the tablet's. Plus no safe-area inset, so the rail sits under the system status bar. The rest of the chrome does not have this problem; onboarding is the outlier. One correction worth recording, since it nearly became a finding: an apparent **duplicate step rail** in two screenshots was an artifact of the downscaled renders being read, not of the devices. A row-luminance profile of the full-resolution captures shows a single rail on both — content bands at the top (status bar, rail, headline), the meter, the CTA, and the system gesture pill, with nothing between. Measured, not eyeballed.

aiko closed this issue

2026-07-30 14:10:59 +00:00

aiko referenced this issue

2026-07-30 14:10:59 +00:00

Wayfinder map — the conversation works (v1) #41

aiko referenced this issue

2026-07-30 14:18:35 +00:00

Unify the log across mobile and tablet #34