1.4.1.9P#CoreCompatPreview

Update TODO

1.4.1.8SEWC#CoreCompatPreview

The Core Wireless release established the capability-driven LSA architecture:
providers publish what Android can actually offer, modules select a backend,
and Linux receives the result through a normal or normal-like interface.

This release applies that architecture to the parts of a Linux desktop that
must work together before the project can be useful as more than a framework:
display, desktop session ownership, audio input and output, camera capture and
recording, location, sensors, storage, private device nodes, D-Bus, graphics,
and safe handling of the Android nosuid boundary.

The important change is that the matrix is now result-led. A provider existing
in source, or a backend reaching RUNNING, is not recorded as a working feature
until a Linux-facing client has exercised it. A failure is kept in the matrix
instead of being hidden by a lower-tier fallback.

This release was developed and tested on the Blackview N6000 running Android
13 / API 33 / arm64. That is the reference device, not a claim that every
Android 8+ device already behaves the same way.

Core Compatibility matrix

LSA now ships a compatibility matrix alongside the source. It separates:

• implemented provider/backend pairs;
• framework selection and lifecycle evidence;
• real Linux-facing data-plane evidence; and
• work that remains open.

The current N6000 ledger includes the following witnessed paths:

Audio output       Android AAudio/HALAudio -> Linux Pulse AndroidSink -> speaker
Camera             Android Camera -> Linux V4L2 MJPEG -> ffmpeg
Recording          camera-record -> bounded H.264 MP4
Location           Android location -> GPSD TPV / no-fix TPV
Sensors            Android SensorManager -> FUSE IIO -> Linux IIO clients
Display            Termux:X11 -> LSA Shell on :0
VNC desktop        TigerVNC :1 -> LXDE / Openbox / panel
Storage            Android public-volume export and Debian NTFS ownership path
GPU                Android ANGLE/Mali -> VirGL/virpipe -> Linux OpenGL client
Video encode       N6000 DMA-BUF -> MediaTek V4L2 -> H.264
D-Bus              private suid clone -> system bus -> service activation

The full matrix remains the source of truth. It records failed fallback tests,
partial results, and device-specific evidence next to successful paths.

Display and phone shell

The experimental LSA phone shell has moved out of the isolated development
session and onto the physical Termux:X11 display.

Android-facing display       :0       LSA Shell, running as myuser
VNC development workspace    :1       LXDE, Openbox, and LXPanel

The real :0 session is no longer a temporary LXDE desktop. It starts
lsa-session, hands ownership to myuser, uses the same LSA GPU, audio,
camera, and sensor environment as a normal application session, and starts
the custom phone-oriented shell.

The VNC desktop remains useful for inspecting a normal desktop environment
without taking over the physical phone display. A fresh :1 server was tested
with LXDE, Openbox, LXPanel, and an X11 client.

Termux:X11 and TigerVNC do not authenticate the same way. TigerVNC creates a
root Xauthority cookie before its startup script runs. Termux:X11 can expose a
valid no-cookie display. lsa-session now transfers a cookie to myuser only
when one exists, and otherwise continues with the no-auth Termux:X11 session.
That prevents the old failure where a valid :0 display could not start the
user shell because there was no root Xauthority entry to copy.

The shell includes the application library and home-screen pinning work from
this compatibility cycle:

• applications are discovered from standard desktop entries;
• the library shows application icons and names;
• applications can be added to the home screen;
• holding a home-screen application exposes a remove action; and
• the launcher terminal uses Bash so history, arrows, and Tab completion work.

Audio

The normal audio route is back on the Android AAudio/HALAudio provider:

Linux application
        ↓
PulseAudio AndroidSink / AndroidSource
        ↓
LSA Android audio provider
        ↓
Android audio routing
        ↓
built-in speaker, microphone, or Android Bluetooth route

A Linux Pulse tone reached the phone speaker through the default
audio.aaudio-halaudio backend. Firefox playback was also restored through
the Android side of the route. Microphone and output endpoints are visible to
ordinary Linux clients instead of requiring each application to talk to an LSA
command directly.

The release also keeps the fallback work honest. The following backends were
force-selected and given a real speaker test:

android.opensles          -> audio.opensles             selected, no output
android.sox               -> audio.sox                 speaker output passed
android.pulse-proxy       -> audio.pulse-proxy         selected, no output
android.termux-api-audio  -> audio.termux-api           selected, no output

Those failures remain failures. The rejections were cleared after testing, so
normal selection returns to the AAudio/HALAudio path.

PulseAudio WebRTC echo cancellation is now wired as an LSA fallback. It creates
LSAAecSource and LSAAecSink from the normal Android source and sink, and
selects them as the Pulse defaults when the AEC policy is enabled. Android
native AcousticEchoCanceler is not claimed yet: it requires an Android-owned
recording session that the present capture provider does not own. A real
speaker/microphone voice-call echo result is still needed.

Camera, recording, and location

Camera is no longer only a rough Android snapshot helper. The generic Camera
provider exposes an Android capture route in the form Linux software expects:

Android Camera API
        ↓
LSA capture provider
        ↓
MJPEG stream / snapshot endpoint
        ↓
Linux V4L2 compatibility path
        ↓
ffmpeg and normal V4L2 clients

A Linux ffmpeg V4L2 client captured three distinct 960x1280 MJPEG frames.
The recording path wrote a decodable bounded H.264 MP4 from the same camera
route. The direct Android-MJPEG fallback was also force-tested with a real JPEG
snapshot and decodable MP4.

Location now behaves better when no live fix is available. A GPSD client no
longer connects successfully and then receives silence. Active location
returned a mode-3 TPV. Inactive location returns a valid mode-1 no-fix TPV so
navigation clients can distinguish “no current fix” from a dead provider.

The remaining camera work is continuous native Camera2 capture, restart and
route tests, and broader graphical camera-application testing.

Sensors and private devices

The SensorBus-to-IIO route is now treated as a normal Linux compatibility
surface rather than a demo service.

Android SensorManager
        ↓
LSA SensorBus
        ↓
FUSE IIO registry and sysfs
        ↓
/dev/iio:* compatibility
        ↓
iio-sensor-proxy and Linux sensor clients

Native IIO devices are exposed, an accelerometer buffer delivered real bytes,
and the iio-sensor-proxy launcher now points at the installed
LSASensorProxy.py location. The previous launcher path referred to the wrong
directory.

The private device namespace also now explicitly preserves public /dev/pts.
A myuser pseudoterminal was allocated and reopened through the normal Linux
path. This protects the Android host /dev from being used as the Debian
namespace while keeping SSH, terminals, and interactive shells functional.

Storage and removable USB media

Removable storage has an ownership model instead of a single mount rule.

Android-recognized public volume
        ↓
Android / vold owns the filesystem
        ↓
exported into Debian at /media/android
        ↓
visible to both Android and Debian

Android-rejected filesystem, such as NTFS
        ↓
Debian owns the filesystem through ntfs-3g
        ↓
mounted only in Debian at /media/debian

The N6000 tested an Android-rejected NTFS USB volume mounted read/write in
Debian at /media/debian/MEOW-50561161561148DC. The Android public-volume
export implementation is present, but it remains marked as needing a witnessed
Android-mounted removable-media test and eject/reconnect coverage.

This avoids pretending that Android and Debian can both independently mount
and modify the same filesystem. Android-owned media remains Android-owned;
Debian can still see it through the exported path. A filesystem Android does
not claim can be handled by Debian without trying to teach Android what NTFS
is.

GPU, Vulkan, and video encode

The generic graphics route is still OpenGL through the Android GPU bridge:

Linux OpenGL client
        ↓
Mesa virpipe / VirGL
        ↓
VTEST socket
        ↓
Android ANGLE / Mali

glxgears completed through the bridge. The GPU policy is injected into normal
Linux sessions, so an application aimed at display :0 inherits the intended
VirGL environment instead of depending on which terminal launched it.

Vulkan is deliberately not advertised. The experimental Venus VTEST route
reaches a VirtIO ring watchdog on the N6000:

MESA-VIRTIO: stuck in ring seqno wait

It is not enabled as a backend. It needs a real client/server protocol fix,

Dolphin Emulator exposed a separate OpenGL limitation. Its VirGL path requires
GL_EXT_clip_cull_distance, which the current phone bridge does not expose.
The installed wrapper falls back to Mesa rather than leaving DISPLAY=:0 dolphin-emu to crash. That is a compatibility guard, not hardware-accelerated
Dolphin support.

The N6000-specific MediaTek encoder remains a separate optional provider. A
1920x1080 DMA-BUF workload produced 12,390 H.264 bytes through the device
route. It is s...

1.4.1.10SEWP#CoreCompatPreview

Between versions 1.4.1.8 and 1.4.1.10, LSA changed how Linux user accounts are handled. Previously, LSA assumed a user named myuser already existed, which caused problems on fresh installations. The updated version automatically creates the account and prompts for a username and password, defaulting to user / user. These changes were made to improve fresh-install compatibility, simplify setup, and ensure user settings persist across restarts and updates.

See version 1.4.1.8 for the major additions and improvements introduced in the previous release.

1.3.1.7SWC#CoreWireless

1.3.1.7SWC#CoreWireless

1.3.1.7SWC#CoreWireless is a LSA release after the capability-driven Core refactor described in 1.2.0.5SWMC#PreCore.

The previous release proved that LSA's individual Android/Linux compatibility systems could coexist as one working full stack.

This release restructures that stack into a capability-driven platform capable of probing an unknown Android device, selecting the best available implementation for each subsystem, falling back when necessary, and exposing those capabilities to Linux through native or native-like interfaces.

LSA is an Android-to-Linux compatibility and capability-brokering layer that creates a Debian Linux userspace on rooted Android and exposes supported Android hardware and services through native or native-like Linux interfaces.

---

Major Core refactor

The previous architecture has been decomposed into independent:

• providers
• modules
• backends
• capabilities
• dependency declarations
• runtime ownership
• lifecycle implementations
• health checks
• compatibility tiers

Hardware compatibility is no longer treated as one device-wide compatibility level.

Each LSA module independently determines the best implementation available for the current device.

The framework currently tracks more than 50 individual capabilities across the platform.

Typical module state now looks like:

Audio               AVAILABLE / RUNNING / Tier A
DeviceNamespace     AVAILABLE / RUNNING / Tier B
Display             AVAILABLE / RUNNING / Tier C
Storage             AVAILABLE / RUNNING / Tier A
Wireless            AVAILABLE / RUNNING / Tier A

Tier letters are local to each module.

A represents that module's best available general implementation.

Z is reserved for the lowest genuine compatibility fallback when one exists.

Empty tier letters are allowed; LSA does not create fake backends merely to fill the alphabet.

---

Capability-driven backend selection

LSA now probes actual capabilities rather than relying on device/version compatibility tables.

A backend can independently report states such as:

AVAILABLE
UNSUPPORTED
ERROR

and administrative policy is tracked separately.

Higher-quality backends can fail without necessarily taking the entire module or platform down.

When possible, the selector continues to the next usable implementation.

Phone model and vendor information may appear in diagnostics, but they are not generic compatibility policy.

Device-specific providers remain possible where genuinely necessary to expose hardware functionality, but generic modules are selected through capabilities rather than model-name branches.

---

Persistent backend rejection

Backends can now be deliberately rejected without pretending that they are unsupported.

Example:

lsectl reject <backend-id>

A rejected backend remains technically:

AVAILABLE

but is marked:

REJECTED BY USER

and the selector proceeds to the next usable backend.

Restore it with:

lsectl accept <backend-id>

The rejection ledger persists across:

• module restart
• RootStart restart
• full deployment
• payload replacement

This provides both a recovery mechanism for malfunctioning implementations and a way to deliberately exercise lower compatibility tiers.

---

Architecture portability

LSA no longer assumes ARM64.

Architecture is now detected and tracked independently across:

• Android ABI
• kernel architecture
• Termux userspace architecture
• Debian/Linux rootfs architecture
• individual bundled ELF assets

Current generic Debian mappings include:

arm64      -> arm64
armv7      -> armhf
x86_64     -> amd64
x86        -> i386

Architecture normalization handles Android/Linux naming differences such as:

arm64-v8a
aarch64

armeabi-v7a
armv7l
armv8l
armhf

Binary providers are architecture-gated independently so an incompatible optional asset does not prevent unrelated modules from operating.

---

ARMv7 portability validation

This release was validated on both the primary ARM64 platform and a deliberately older ARMv7 challenger device.

The challenger is:

Samsung SM-J337P
Android 9
Linux 4.4
ARMv7 Android/Termux userspace
Debian armhf

No Samsung-specific compatibility backend or SM-J337P special case was introduced.

Instead, the device was used to expose generic assumptions in the framework.

Among other things, it validated generic selection of:

CoreChroot          Tier A
Audio               Tier A
DeviceNamespace     Tier B
Display             Tier C
Storage             Tier A
Wireless            Tier A

This was an important portability milestone: several implementations originally developed on the N6000 proved to already be generic once ARM64, lifecycle, PATH, and rootfs assumptions were removed.

---

Deployment system

LSADeploy is now a substantially more complete installer rather than simply a portable snapshot.

Normal installation is:

./deploy.sh

The deployer self-locates, so the caller's current working directory is irrelevant.

A full deployment can:

1. Detect the installed Termux environment and UID/GID.
2. Detect Android, kernel, Termux, and Linux architecture requirements.
3. Validate the deployment payload.
4. Preserve an existing installation before replacement.
5. Preserve the persistent backend-rejection ledger.
6. Install required generic Termux packages.
7. Validate/install bundled Android support applications.
8. Detect existing Debian rootfs state.
9. Bootstrap a new Debian rootfs for the appropriate architecture.
10. Resume an interrupted rootfs bootstrap when safe.
11. Deploy RootStart and NonRootStart.
12. Generate device-local authentication state.
13. Run capability/framework discovery.
14. Start NonRootStart before RootStart.
15. Start the Linux environment.
16. Run post-install validation.

The deployment package intentionally does not contain a prebuilt Debian rootfs.

Debian is built for the target architecture using debootstrap.

---

Framework-only deployment

Capability discovery can be installed without provisioning or starting the complete Linux environment:

./deploy.sh framework-only

This provides:

• architecture discovery
• provider discovery
• backend probing
• capability reporting
• backend selection diagnostics
• persistent backend policy

without requiring a Debian rootfs.

---

Rootfs recovery

Interrupted Debian provisioning can be resumed with:

./deploy.sh resume-rootfs

The deployer distinguishes between rootfs states instead of silently accepting or destroying suspicious partial installations.

---

Durable RootStart lifecycle

RootStart requires terminal semantics for parts of its normal lifecycle.

Deployment now uses a PTY-backed supervisor so RootStart can remain detached while still receiving the terminal environment it expects.

This fixes the earlier condition where a detached deployment could bring the stack up temporarily but fail to maintain a durable RootStart session.

---

Provider/module decomposition

Major platform components have been moved into explicit provider/module ownership.

This includes:

• Camera
• Location
• Sensors
• DeviceNamespace
• Capture
• Audio
• GPU
• Display
• FUSE
• D-Bus
• VideoEncode
• Wireless

Compatibility/lifecycle behavior that previously lived in transitional service wrappers has been moved toward normal module-owned lifecycle paths.

Remaining compatibility entrypoints are documented rather than silently treated as permanent architecture.

---

Device namespace

Linux now uses a private /dev namespace rather than directly treating Android's /dev tree as its own.

Android's host device namespace is available at:

/dev/.host

This allows LSA to safely provide Linux-specific device mappings, proxies, and compatibility nodes without contaminating Android's host /dev.

The current generic private-device implementation is DeviceNamespace Tier B.

---

Audio

Audio is now owned through the Android Audio provider and normal LSA Audio module.

The old fixed 48 kHz output assumption has been removed.

Linux audio negotiates the actual Android-side sink/source format instead.

Validated paths include:

• speaker output
• Bluetooth audio routing
• microphone capture
• negotiated sample rates
• PulseAudio-facing Linux behavior
• Android AAudio-backed transport

44.1 kHz stereo output has been validated without forcing the backend to 48 kHz.

---

GPU

GPUBridge is now owned as an Android provider rather than being treated as an external compatibility service.

Linux GPU consumes the provider's normal runtime socket.

The generic VirGL/virpipe graphics path remains operational.

Validated generic rendering has exceeded 100 FPS in framework regression testing on the primary device.

---

Display

Termux:X11 integration is now owned through the Android Display provider.

LSA's display backend consumes the Linux-facing X11 socket rather than treating display startup as an external lifecycle exception.

The ARMv7 challenger successfully selected the generic Display Tier C implementation without a device-specific provider.

LSA now distributes its own LSA-X11 build derived from Termux:X11.

---

LSA-X11 source provenance

The bundled LSA-X11 APK is no longer an unverified historical prebuilt.

For this release, LSA-X11 was rebuilt from the recorded source workspace and the package records the APK/source correspondence.

The rebuild produces:

arm64-v8a
armeabi-v7a
x86
x86_64

payloads.

The resulting APK retain...

1.2.0.5SWMC#PreCore

1.2.0.5SWMC#PreCore

1.2.0.5SWMC#PreCore is the current known-good full-stack LSA foundation before the next major capability-driven Core refactor.

At this stage, LSA can deploy and operate a coordinated Android/Linux environment using NonRootStart, RootStart, and ModChroot, with hardware and service compatibility layers exposed into a Debian-family rootfs.

Currently supported

• Automated full-stack deployment
• RootStart / NonRootStart service separation and startup ordering
• ModChroot lifecycle management
• automatic preflight and stale-session cleanup
• rootfs injection and provisioning
• modular mount setup and teardown
• private Linux /dev namespace
• Android /dev exposure through /dev/.host
• /dev/shm provisioning
• HALAgent / HALBridge communication
• authenticated HALBridge sessions with per-install secrets
• Android-backed audio through HALAudio / HALAudioS
• speaker output
• Bluetooth audio routing
• microphone capture
• GPS access
• camera photo capture
• Android/device information access
• DNS integration
• System D-Bus support inside the Linux environment
• GPUBridge
• VirGL / virpipe GPU acceleration path
• Termux:X11 integration
• Linux graphical desktop/application support
• HALSensorBus
• Android sensor discovery and transport
• dynamic Linux IIO sensor registry
• synthetic /sys/bus/iio/devices
• FUSE-backed IIO compatibility
• stream sensors
• state sensors
• event sensors
• private userspace /dev/iio:* compatibility
• native event ioctl compatibility shim
• transparent session-scoped event preload environment
• clean runtime state directories
• package/environment manifests
• payload SHA-256 verification
• automatic backup of previous LSA installations during deployment
• portable RootStart and NonRootStart snapshots without bundling the Debian rootfs

Current sensor compatibility

The current sensor stack represents the completed Tier-D Linux IIO compatibility path:

Android SensorManager
        ↓
HALSensorBus
        ↓
LSA sensor brokers
        ↓
dynamic sensor registry
        ↓
FUSE synthetic IIO sysfs
        ↓
private Linux /dev compatibility
        ↓
event ioctl shim
        ↓
normal Linux sensor-facing interfaces

This allows Android sensors to appear inside Debian through Linux-style IIO interfaces rather than requiring applications to directly understand Android's sensor APIs.

Current graphics path

Linux application
        ↓
Mesa / VirGL / virpipe
        ↓
GPUBridge
        ↓
Android GPU

Termux:X11 currently provides the display path for graphical Linux applications.

Current audio path

Linux application
        ↓
HALAudio
        ↓
HALAudioS
        ↓
Android audio stack
        ↓
speaker / Bluetooth / microphone

Current architecture

Termux user
    │
    └── NonRootStart
          ├── HALAudioS
          ├── GPUBridge
          ├── HALSensorBus
          └── DNS
                 │
                 ▼
Android root
    │
    └── RootStart
          ├── HALAgent / HALBridge
          ├── Termux:X11 integration
          └── ModChroot
                 │
                 ▼
          Debian-family Linux

NonRootStart is intentionally started before RootStart.

Deployment

The known-good snapshot contains the complete LSA-owned RootStart and NonRootStart trees while intentionally excluding:

• the Debian rootfs itself
• live sockets
• PID files
• logs and runtime caches
• captured camera/audio data
• the source device's HAL authentication secret

The deployment system verifies its payload, backs up an existing installation, adapts ownership to the target Termux UID/GID, generates new authentication state, and reconstructs the required runtime environment.

Known-good Android-side baseline

Currently developed and tested with:

Termux      0.118.3
Termux:API  0.53.0
Termux:X11  bundled/current known-good build

Current development uses the SELinux Permissive lane.

---

1.2.0.5SWMC#PreCore is essentially the last major "prove that all of the individual compatibility systems can coexist as one working stack" stage.

The next move is the Core refactor: converting these existing working systems into independent capability-probed A–Z module tiers so LSA can automatically determine the best implementation available on an unknown device.

LSA-V1.1

Completed:

GPS

Camera -- photos only

Speakers/Bluetooth -- Full Audio Routing Automated

Microphone recordings

Security Patch

CPU Puppet Control

LSA-V1

Completed:

GPS

Camera -- photos only

Speakers/Bluetooth -- Full Audio Routing