makepad

History

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
..
theme.splash	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	2026-09-23 22:34:44 +02:00
widgets.splash	widgets: glass, dock, tweaker, themes, code_editor, phone shell	2026-09-15 13:38:48 +02:00