Skip to content

1.3.1.7SWC#CoreWireless

Choose a tag to compare

@Phsphorus Phsphorus released this 07 Sep 17:21
· 14 commits to main since this release
8f9a45e

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 retains the previous signing identity for Android upgrade compatibility.

LSADeploy includes:

  • LSA-X11 build provenance
  • APK SHA-256
  • corresponding source snapshot
  • source archive SHA-256
  • license/source information

The public LSA-X11 project is available at:

https://github.com/Phsphorus/lsa-x11


Sensors / Linux IIO

The Linux IIO compatibility path from the previous release remains intact through the Core refactor.

The sensor stack includes:

Android SensorManager
        ↓
Android sensor provider
        ↓
LSA Sensor module
        ↓
dynamic sensor registry
        ↓
synthetic Linux IIO sysfs
        ↓
private /dev compatibility
        ↓
event ioctl compatibility
        ↓
normal Linux sensor-facing interfaces

Validated behavior includes:

  • native sensors
  • synthetic sensors
  • stream sensors
  • state sensors
  • event sensors
  • dynamic registry generation
  • FUSE-backed IIO sysfs
  • /dev/iio:* compatibility
  • event ioctl handling
  • actual sensor sample transfer

On the primary platform the current registry has exposed:

2 native
20 synthetic

IIO devices during validation.


FUSE

FUSE now follows normal module lifecycle ownership.

Device publication belongs to DeviceNamespace, while individual consumers such as Sensors own their own FUSE mounts.

This reduces cross-module lifecycle assumptions and makes teardown ownership explicit.


D-Bus

System D-Bus is now managed through a normal module-owned lifecycle.

The daemon uses explicit process ownership rather than relying on historical PID-file behavior.

Validated operation includes a standard Linux system-bus round trip using dbus-send.

D-Bus is also part of normal automatic startup rather than requiring a separate compatibility action.


Storage

Storage now includes a real compatibility ladder.

The current implementations include:

Tier A
Android shared-storage path

Tier Z
Termux ~/storage/shared compatibility path

Backend rejection was used to validate:

Tier A
→ reject A
→ Tier Z selected
→ restart
→ Tier Z retained
→ accept A
→ Tier A restored

The storage data plane was also validated with actual create/read/delete operations.


Video encode

An optional device-specific VideoEncode provider remains available where the hardware path can be proven.

On the primary N6000 platform, the MediaTek path has produced a real H.264 artifact through:

DMA-BUF
    ↓
MediaTek V4L2
    ↓
H.264

The optional VideoEncode service remains separate from normal generic GPU operation.

Generic VirGL operation is restored after the video path is stopped.

H.265 is not advertised without corresponding operational evidence.


Wireless

Wireless is now a baseline LSA module.

The goal is to expose Android wireless capabilities to Linux as natively as the available kernel/Android stack permits.

The module performs non-destructive capability discovery and distinguishes between:

advertised
probed
operationally verified
unsupported
unknown/unverified

rather than treating driver advertisement as proof.

Current discovery includes evidence for areas such as:

  • 2.4 GHz / 5 GHz availability
  • Linux-visible wireless interfaces
  • managed mode
  • AP advertisement
  • IBSS advertisement
  • P2P support
  • NAN/Aware framework evidence
  • interface concurrency
  • wireless metrics
  • raw-radio primitives

Operations that cannot be safely verified without disturbing the active Android Wi-Fi/SSH connection remain explicitly unverified.

LSA does not claim support merely because a driver advertises a feature.


Wireless Tier A

The generic Tier A backend exposes Android's existing host wireless interface to the Debian environment through ordinary Linux networking surfaces.

For example:

Android wlan0
      ↓
LSA Wireless Tier A
      ↓
Linux /sys/class/net/wlan0
Linux /proc/net/dev
normal sockets

Both current test devices independently selected and ran the generic Tier A implementation.

No model-specific Wireless provider was required.


Wireless Tier Z

A genuine Termux-backed socket/uplink compatibility backend exists as Wireless Tier Z.

It provides a lower-fidelity but real Linux networking fallback when the native host-interface path cannot be selected.

Backend rejection was used to validate:

Tier A AVAILABLE / RUNNING
        ↓
Tier A REJECTED BY USER
        ↓
Tier Z AVAILABLE / RUNNING
        ↓
Tier A accepted
        ↓
Tier A AVAILABLE / RUNNING

The transition does not take ownership of or reset Android's active wlan0.


Real two-device Wireless validation

Wireless Tier A has passed an actual data-plane test.

A Debian rootfs on one phone transmitted a UDP datagram through its Linux-visible wlan0 to the other phone, and received a response.

A later test validated the exchange with both devices operating through their Linux rootfs networking paths.

Conceptually:

Phone A Debian rootfs
        ↓
LSA Wireless Tier A
        ↓
Android wlan0
        ↓
Wi-Fi network
        ↓
Android wlan0
        ↓
LSA Wireless Tier A
        ↓
Phone B Debian rootfs

Bidirectional data transfer succeeded.

This is a real packet-transfer validation rather than an interface-presence-only test.

More advanced peer-radio functionality including:

  • 802.11s
  • NAN / Wi-Fi Aware data paths
  • IBSS join
  • P2P groups
  • raw management/action-frame transport

is not claimed as working until it can be operationally verified safely.


HALAgent security hardening

HALAgent authentication and logging have been hardened.

Current generated state uses:

state directory       0711
secret directory      0700
secret file           0600

Unsafe historical authentication material is rotated rather than merely having its permissions changed.

Authentication/control requests are no longer dumped raw into normal logs before authorization.

The deployment release contains no source-device HAL secret.

Each target receives new device-local authentication state.


Startup and failure isolation

LSA startup is now more tolerant of optional capability failure.

Examples exposed during portability testing include:

  • absent Termux:X11
  • absent cloudflared
  • unavailable optional sensor dependencies
  • inaccessible GPU paths
  • unsupported camera/location implementations
  • architecture-mismatched binary assets

These conditions are intended to remain local to the affected capability instead of aborting the complete LSA stack.

Slow devices are also handled more conservatively; framework probing and Android diagnostic surfaces are bounded where appropriate rather than being allowed to hang indefinitely.


Current high-level architecture

                    Android
                       │
        ┌──────────────┴──────────────┐
        │                             │
 NonRootStart                     RootStart
        │                             │
 Android/Termux providers        Android/root providers
        │                             │
        └──────────────┬──────────────┘
                       │
                  LSA Framework
                       │
             capability discovery
                       │
              provider selection
                       │
              A-Z backend tiers
                       │
                    Modules
                       │
                   ModChroot
                       │
              Debian Linux userspace

NonRootStart remains intentionally started before RootStart.


Deployment contents

The release contains the LSA-owned deployment payload while intentionally excluding transient/device-specific runtime material such as:

  • prebuilt Debian rootfs
  • live sockets
  • PID files
  • runtime logs
  • runtime caches
  • camera/audio captures
  • Python bytecode
  • source-device authentication secrets

The package includes:

  • payload SHA-256 records
  • APK hashes and versions
  • source provenance information
  • architecture policy
  • ownership policy
  • LSA-X11 corresponding source
  • third-party license information
  • package/source manifests

Existing installations are preserved before payload replacement.


Licensing

LSA-authored material is licensed under the Apache License 2.0.

Separately distributed components retain their respective licenses.

LSA-X11 is derived from Termux:X11 and is distributed under GPL-3.0.

Termux:API also retains its GPL licensing.

The release includes:

LICENSE
NOTICE
THIRD_PARTY_NOTICES.md
SOURCE_AVAILABILITY.md
LICENSES/
manifest/SOURCES.tsv
manifest/LSA-X11-BUILD.tsv

for redistribution/source information.


Known-good Android-side baseline

Current development/testing includes:

Termux       0.118.3
Termux:API   0.53.0
LSA-X11      bundled LSA build

Current development remains on the SELinux Permissive lane.


Deployment

Extract LSADeploy to an executable location on the target device.

For example:

cd /data/local/tmp/LSADeploy
chmod +x deploy.sh
./deploy.sh

For capability/framework discovery without creating a Debian rootfs:

./deploy.sh framework-only

To resume an interrupted Debian bootstrap:

./deploy.sh resume-rootfs

After installation, a detailed platform report can be requested with:

lsectl report --verbose