Add Android AMY Oboe service over private Unix socket

[linuxificator]

Summary

Adds a private Linux/Android Unix-domain AMY transport plus a generic Android AAR that runs AMY + Oboe in an unexported :amy service process. Any Android client packaged with the AAR can control the synth through the private AMY wire socket; the AMY Android layer has no dependency on a particular UI toolkit or application framework.

Private transport

• AF_UNIX + SOCK_SEQPACKET
• one connected client
• socket pathname mode 0600
• Linux/Android SO_PEERCRED same-UID check
• stale pathname removal only for same-UID socket files
• never removes an existing regular file
• bidirectional packet API for future introspection replies
• fixed 64-packet SPSC receive queue

The receiver thread never calls AMY. The audio/control owner explicitly drains packets at a safe AMY block boundary.

Android AMY/Oboe AAR

• generic Android library/AAR under android/
• unexported org.amy.audio.AmyService
• service runs in android:process=":amy", so it shares the host application UID but has a separate process/runtime
• service accepts only <Context.getFilesDir()>/amy.sock
• JNI is lifecycle-only: start/stop native engine; musical control stays AMY wire over amy.sock
• client may be Kotlin/Java, native Android, Qt, or another framework capable of starting the service and using AF_UNIX/SOCK_SEQPACKET
• AMY miniaudio backend is not linked
• Oboe 1.10.0 Prefab dependency
• 48 kHz, stereo I16, LowLatency, Exclusive
• AMY uses 128-frame blocks; arbitrary Oboe callback sizes consume the current AMY block directly, with no additional 128-frame output ring
• command queue is drained immediately before rendering each new AMY block
• AMY rendering is single-owner on the Oboe callback thread
• current Android configuration reserves 16 Karplus-Strong oscillators
• current ABI target: arm64-v8a

Client contract

A host Android application needs only to package the AAR, start AmyService, determine its private filesDir, connect to <filesDir>/amy.sock, and send one ordinary AMY wire message per SOCK_SEQPACKET packet. The socket is bidirectional for replies/status. No AMY-specific JNI calls are required for musical control.

The pathname is intended to be a readiness boundary: the service publishes/listens on amy.sock only after Oboe has started and its realtime callback has executed at least once. A client can therefore retry connect() until the socket exists/accepts and then begin sending AMY wire packets without an application-specific startup delay.

Build/test

• standalone Linux socket regression: bash tests/run_amy_unix_socket_test.sh
• .github/workflows/android-unix-socket.yml validates the private Unix socket transport
• .github/workflows/android.yml validates the socket path and builds the complete Android AAR with JDK 17 / API 36 / NDK 27 / CMake 3.22 / Gradle 8.13
• Android workflow uploads amy-service-debug-aar

Scope / hardware follow-up

• ordinary AMY wire input is implemented now
• the socket is already bidirectional; compact introspection replies can be layered on after the introspection branch is merged/rebased
• hardware testing should measure command-to-audio latency, Oboe callback/buffer sizes, xruns during patch allocation and heavy FX, and lifecycle/device-change behavior