Keep device examples as independent ARM/Thumb Linux, x86 Linux, and Android targets

[isomorphisms]

Standing requirement — 2026-09-11

The phone is the user's current workbench, not the specification or the limit of Idriç's device examples. A device operation discussed while experimenting on Android must be translated into the corresponding ordinary-system targets rather than silently becoming Android-only.

In particular, difficulty showing a red screen from a tiny ARM/Thumb executable on the phone must not cancel the ARM/Thumb Linux or x86 Linux program. Bionic, Termux, and PRoot experiments may improve the phone path, but neither Linux target depends on those experiments succeeding.

This issue registers implementation targets and acceptance requirements. It is not an assertion that these programs, guests, or checks have already been built or run. Reuse any existing exact-revision evidence after inspection; do not infer support from this inventory.

Independent target profiles

Every example below must retain these target entries:

Profile	Required meaning
ARMv7 / Thumb-2 / ordinary Linux	A real ARM/Thumb executable, built and run in a full-system cloud guest with a conventional Debian userspace/filesystem and a declared Linux kernel/device configuration. This is not Android under another directory tree.
x86-64 / ordinary Linux	Its own native x86-64 executable and full-system cloud guest with conventional Debian userspace/filesystem and declared devices. Additional direct Debian-host execution is useful but must not silently replace the requested emulated-system coverage.
Android phone	A separately identified phone implementation, recording the actual ABI, runtime/API or helper, permissions, and device support. Keep direct ARM/Thumb development and any DEX/ART + JNI application-delivery path separately labeled.

Record ISA/instruction mode, ABI, kernel, userspace/libc or no-libc choice, filesystem layout, device interface, privilege/session requirements, and execution environment separately. Similar directory names do not establish the same device interface. A conventional Debian filesystem alone does not assert that a display, camera, GPIO controller, or sensor is present and usable.

The user's existing Debian runner policy remains in force: isomorphisms/ai-ci#83. Select and pin actual guest images/kernel configurations during implementation; this issue does not claim that a guest image is provisioned.

Canonical example inventory

These are program targets, not merely prose examples or byte-buffer generators.

Family	Programs to preserve	Observable acceptance direction
Screen	Show the whole selected display red; show half red / half blue; timed colour changes	Verify presented guest display output, dimensions, split boundary, duration/sequence and cleanup. A generated image file or a coloured buffer alone is a lower-level test, not display acceptance.
Sound / speaker	A tone; two different tones with pauses; the previously discussed short Beethoven-like rhythm	Capture output downstream of the selected emulated audio device and check pitch, silence and duration. Buffer generation and actual speaker/audible output are separate evidence. Do not silently equate PCM playback with a PC-speaker mechanism.
Sensors	Read an accelerometer and other available sensors, once and as a stream	Preserve sensor identity, units, axes where relevant, timestamps and sample/error behavior; use known injected samples for simulator tests and separate physical-device receipts.
Camera	Capture one frame and a short frame stream	Check dimensions, format, frame identity/order and cleanup. A declared virtual camera/test source is valid virtual-device evidence, not a physical camera result.
Microphone	Capture samples, including a bounded recording	Check captured data and timing from a declared input source; distinguish virtual input from physical microphone capture.
Visible light	Turn the flashlight/LED on and off; a timed pulse	Observe state transitions and off/release behavior. Keep camera-flash torch access, LED control and GPIO-driven lighting as different implementations where applicable.
Infrared	Turn an infrared emitter on/off or send an explicitly defined pulse sequence	Name emitter/controller capability and inspect transitions/timing. Do not assume the phone or ordinary PC contains an IR emitter; do not substitute a visible flashlight.
GPIO	Drive a selected output high/low; pulse it; read an input and wait for an edge	Name chip/line, direction, polarity, ownership and timing; distinguish a simulated line trace from measured physical voltage/edges.

New device examples discussed later join the same target accounting. Do not remove an inconvenient example or target merely to make an aggregate report green.

Source and implementation structure

Idriç owns the operation's meaning and shared behavioral fixtures. ARM and x86 owners provide their own code generation, ABI handling and platform implementations. Android-specific adapters remain Android-specific.

The ordinary source should express the action—show a colour, play a tone, read a sensor, capture a frame, switch a light, drive a pin. Raw ioctl, syscall numbers, register layouts, Binder/NDK details and foreign calls belong in the inspectable implementation beneath that action, not as mandatory top-level vocabulary.

This fits the ordinary file/module mechanism selection in #75. It does not require a universal POSIX-fd abstraction, an Android runtime copied onto Debian, or new Adriç compiler features before useful work begins.

Preserve the tiny native-program investigation as a distinct implementation form: hand-written assembly and small syscall-level executables are useful concrete probes. An assembled Thumb probe is not proof that Idriç's compiler emitted it. Retain source/compiler/backend identity and disassembly where native codegen is claimed. A practical library or Android helper is a separately named mechanism, not a silent replacement for the requested direct native target. No new RefC/generated-C dependency is authorized (#38).

Evidence must say what ran

Keep independent facts for:

1. source/semantic fixture checks;
2. compilation/linking and target-code inspection;
3. user-mode emulation or direct host execution;
4. full-system guest execution through a named kernel/device interface;
5. simulated/injected versus passed-through physical device;
6. physical phone or other physical-device observation.

Record exact source/compiler/backend revisions, binary hash, guest image/kernel identity, emulator version and machine/device arguments, execution mode/acceleration, fixture identity and resulting capture/log.

A full guest may use a simulated camera, audio source, sensor or GPIO controller where suitable. Identify the exact model and exercised boundary. If a model is missing, record implementation/model work or a narrower fixture as pending; do not call a mocked return value hardware support. Real hardware remains a separate target obligation, not a reason to abandon cloud tests.

For each example/profile keep an implementation state, execution state and blocker/evidence reference. NOT_BUILT, NOT_RUN, BLOCKED, failed checks and absent hardware must remain visible. A successful test of the permission-denied path is not successful execution of the requested operation. Android being blocked must not mark the Linux targets not-applicable; lack of hardware in one guest must not remove the program from the inventory.

Cross-repository ownership

• Idriç: canonical inventory, semantic actions and behavioral fixtures (this issue).
• ARM/Thumb: isomorphisms/idric-arm-thumb, with existing sequencing authority in Sequence IB-derived ARM/Thumb work behind native Idriç gates idric-arm-thumb#31. Keep this newly registered workload separate from the acceptance claims of whichever compiler slice is currently being implemented.
• x86: isomorphisms/idric-x86-aggressive-backend; independent target-native implementation, not Thumb instruction copying.
• AICI: account for these explicitly requested workloads in Track ARM/Thumb follower propagation with per-target mutatis-mutandis policy ai-ci#20 and existing mobile/cloud follow-through. The generic policy's permission not to port every workload must not erase these specific user-requested targets. Leave actionable queued work for missing rows; a comment is not an installed enforcement check.
• Cat Food: package applicable runnable outputs under Enforce whole-inventory Cat Food delivery: host builds and phone/tablet runtimes ai-ci#10 / Whole-inventory Android delivery: independent DEX/JNI builds and runtime-only installs catfood#33. Ordinary Android delivery remains independent of unfinished native compiler backends; packages, emulator receipts and physical installation remain separate facts.
• ish/Grease: assess command/orchestration counterparts where useful, particularly source waiting and timers in Make waitable input sources explicit: terminal input, pipes, and portable readiness grease#18. This is a possible consumer, not a claim that Grease/Oils libc is the ish runtime or an instruction to duplicate every device backend in the shell.

Implementation checklist

• Add/reconcile a canonical machine-readable example × target registry and links to existing fixtures.
• Make missing target entries detectable rather than silently skipping them.
• Establish the full-system ARMv7/Thumb Debian guest profile and capture path.
• Establish the full-system x86-64 Debian guest profile and capture path.
• Build and demonstrate the red / split-colour programs on both Linux profiles, with native code identity and presented-output evidence.
• Add the tone-and-pause program on both Linux profiles with captured audio evidence.
• Keep sensors, camera, microphone, visible light, infrared and GPIO as explicit tracked implementation targets; select honest simulated-device/hardware test arrangements for each.
• Record Android mechanisms and blockers independently, including optional Bionic/Termux/PRoot experiments.
• Review applicable ish/Grease commands and event-source semantics without asserting an existing runtime integration.
• Wire the registry into AICI and applicable Cat Food inventory/delivery checks; documentation alone does not complete enforcement.

Technical boundary references

• QEMU system emulation models a complete machine with a guest OS: https://www.qemu.org/docs/master/system/introduction.html
• QEMU user-mode execution is a different boundary: https://www.qemu.org/docs/master/user/main.html
• PRoot explicitly uses the host kernel, not a guest kernel: https://proot-me.github.io/
• Android's kernel-level app sandbox also applies to native code: https://source.android.com/docs/security/app-sandbox
• Linux GPIO character-device API and device-specific constraints: https://docs.kernel.org/userspace-api/gpio/chardev.html

No runtime support or new passing acceptance result is claimed by opening this issue.

[isomorphisms]

Concrete ARM/Thumb reference added for the screen-red target.

Backend source (handwritten Thumb-2, syscall-only; not compiler-generated evidence):
https://github.com/isomorphisms/idric-arm-thumb/blob/38e7af8abe7009c5ed86fa8418d9f13d7375ba36/tests/framebuffer/linux_fbdev_red.S

Cross-compiled artifact:
https://github.com/isomorphisms/idric-arm-thumb/blob/38e7af8abe7009c5ed86fa8418d9f13d7375ba36/artifacts/linux-fbdev-red.armv7-thumb2

Build receipt + SHA-256:
https://github.com/isomorphisms/idric-arm-thumb/blob/38e7af8abe7009c5ed86fa8418d9f13d7375ba36/artifacts/linux-fbdev-red.armv7-thumb2.BUILD.md

This gives #85 a concrete implementation/reference target for the eventual source-level Idriç action “show the selected display red.” The compiler contract should remain device-independent; fbdev/openat/ioctl/mmap are one Linux adapter, not the surface syntax or semantic definition. The artifact is ELF32 ARM EABI5 Thumb-2, static, no libc/Bionic runtime calls. It has been cross-compiled and inspected, but not yet executed against a real fbdev device or physical Android display.

Grease/Ish cross-reference: isomorphisms/grease#18. That side should preserve the device/event-source modeling question without assuming that every useful device is necessarily a POSIX fd or that the current Grease/Oils libc is the ish runtime.

[isomorphisms]

Phone-side follow-through is now concrete in Ashtray-Archer/utilities-android-phone-user#43, with Ish/Grease consumer tracking in isomorphisms/grease#23.

For Idriç, preserve the semantic layer above mechanism:

/hardware/sensors/accelerometer/info
/hardware/sensors/accelerometer/sample
/hardware/sensors/accelerometer/events
/hardware/sensors/accelerometer/control

This is initially a synthetic namespace, not a requirement for a Linux mount. sample is the canonical tiny action: read one accelerometer measurement, write x y z in documented units, exit. The Android implementations may differ underneath while implementing that same action.

Preserve independent mechanism examples where feasible:

accelerometer/android-api
accelerometer/binder
accelerometer/linux-device
accelerometer/hal

Start with NDK libandroid / ASensorManager; also retain the Termux:API Android-service bridge as a separate backend. Then work downward experimentally to direct Binder, sensors HAL, kernel /dev//sys/IIO/input/vendor interfaces, and only then bus/register-level access if an ordinary process can actually reach it. Permission/SELinux failures remain evidence, not successful hardware support.

The existing ordinary ARM/Thumb Linux and x86 Linux obligations in this issue remain independent: Android's file-like namespace is a platform adapter, not the universal implementation and not a reason to drop the direct Linux versions.