2 commits

Author	SHA1	Message	Date
Admin	e603d6ae84	wm on Android: apps build on the phone -- the multi-process WM's APK can now carry the toolchain, source tree and prebuilt target/ (proc-pack --proc-toolchain=<tc>, written as wm-proc-ondevice.apk), like wm-dyn's super-app, but without the engine dylib: each app is a small generated wrapper crate linking the engine statically, so an on-device cargo build reuses the shipped engine rlibs and compiles only the app. With debug.makepad.wm.ondevice=1 the launcher (--build) builds the app before loading it; builds take turns on a lock, each finished library is copied to its own file in files/run/ and loaded from there, and a build or lock wait past its deadline (300 s, 600 s for the first proc-macro bootstrap) is killed with its process group and the APK's prebuilt library runs instead. Provisioning, unpacking and the proc-macro bootstrap moved out of the WM's dylib host into libs/ondevice_build, shared with wm-dyn (streaming LZ4 parts, same stamps and paths); dyn-pack's staging was factored so proc-pack reuses it. The debuggable switch is opt-in and only for the on-device APK. Proven on a Pixel 11 Pro XL: calculator's source edited in the phone's copy rebuilt in 12.7 s and showed the change; four apps built in turn in about 6 s each ... Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-23 22:34:44 +02:00
Admin	a8bf0e4dcf	wm on Android: every app is its own process -- the plain makepad-wm now ships as an Android APK (cargo makepad android ... proc-pack -p makepad-wm-android) whose phone apps run as real child processes instead of dylibs loaded into the WM. The interface between WM and app shrinks to what the desktop WM uses: shared GPU buffers and the StudioToApp/AppToStudio protocol. The WM allocates each app's swapchain as AHardwareBuffers and hands them over a unix socket (AHardwareBuffer_sendHandleToUnixSocket, API 26); the child, started through the libmakepad_launch.so launcher in nativeLibraryDir (W^X allows it there), imports them into a windowless Vulkan device and renders its window pass into them (android_hosted.rs). Each app library links the engine statically, so the engine-dylib identity handling of wm-dyn is not needed. Children have no JVM: assets are read from the APK file, audio device lookup no longer goes through Java, and the startup/resize extra draw of the Activity build is repeated so the first frame carries its text. On a phone the WM asks for the soft keyboard only while the child reports a focused text field. Proven on a Pixel 11 Pro XL: all twelve phone apps launch as processes (first frame 1.6-2.4 s cold), taps reach them. Not yet: HTTP in children (the Activity build borrows Java's), clipboard/permission/file-picker relays, idle-app reclaim, and on-device builds of app libraries ... Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-23 22:34:44 +02:00