2 Commits

Include renames

Author	SHA1	Message	Date
swung0x48	6c7ad0a1bf	[Feat] (Spikes): add the standalone external-memory probe that decides the persistent-map tier ... - Plan B §11 P0 requires spike B ("external memory 导出，两台设备") to run before the persistent-map decision of §8.3 can be taken: T0 (server imports a client allocation), T1 (server exports its own HOST_VISIBLE|HOST_COHERENT allocation) or T2 (AcquirePersistentMap returns nullptr, making the §5.10 client-side block push mandatory). §8.3 says the answer must be measured on the two campaign devices, and that a platform unknown must not block the interface work. - tools/spikes/extmem_probe/ is a self-contained NDK command-line program: it links vulkan/EGL/GLESv3/android/log and nothing from MobileGL, is configured by its own CMakeLists with the android toolchain file, and is deliberately absent from the project's build graph (the root CMakeLists only pulls in tools/trace_replay), so the default ALL target is untouched. - Phase A enumerates VK_KHR_external_memory_fd, VK_EXT_external_memory_dma_buf, VK_EXT_external_memory_host, VK_ANDROID_external_memory_android_hardware_buffer and, through a headless EGL pbuffer context, GL_EXT_memory_object{,_fd}, GL_EXT_external_buffer, GL_EXT_buffer_storage, GL_OES_EGL_image_external{,_essl3} and EGL_ANDROID_get_native_client_buffer, plus the memory-type table and the vkGetPhysicalDeviceExternalBufferProperties verdict per handle type for the exact buffer usage set MobileGL needs. - Route T1 allocates a HOST_VISIBLE|HOST_COHERENT buffer memory with VkExportMemoryAllocateInfo, writes a pattern through vkMapMemory, exports an fd with vkGetMemoryFdKHR (opaque-fd and, where advertised, dma-buf), hands it to a second process over SCM_RIGHTS, and has that process both mmap() the fd and import it into its own VkDeviceMemory + vkMapMemory. Both sides write and both sides compare, so a copy-on-import or one-directional mapping is reported as PARTIAL rather than as success. - Route T0 has the second process allocate an AHardwareBuffer BLOB (CPU_READ_OFTEN|CPU_WRITE_OFTEN|GPU_DATA_BUFFER), send it with AHardwareBuffer_sendHandleToUnixSocket, and the first process import it three ways -- AHardwareBuffer_lock, VkDeviceMemory via VK_ANDROID_external_memory_android_hardware_buffer, and a GL buffer via eglGetNativeClientBufferANDROID + glBufferStorageExternalEXT mapped persistent/coherent -- with a write-back leg the allocating process verifies. - Route T3 covers VK_EXT_external_memory_host: a memfd-backed mmap region aligned to minImportedHostPointerAlignment, imported through VkImportMemoryHostPointerInfoEXT, plus the same memfd handed to another process. - The second process is /proc/self/exe re-exec'd with --child=<route> and one end of a socketpair on fd 3. A bare fork() is not usable: neither side's Vulkan driver survives fork, and both sides need live Vulkan. It is also the topology the transport actually has (§8.1, inheriting PLAN.md §11.1-§11.6: the client spawns the server), so the probe measures the arrangement that would ship. - The probe also builds for the host with T0 compiled out. That is not scope creep: a negative device result is only worth something if the harness is known to report a working route as working. Running it on lavapipe did that, and paid for itself immediately by exposing two harness bugs that would have produced false negatives on the devices -- (a) the child wrote through its plain mmap before reading through the Vulkan import, so on a driver whose exported fd maps at an offset the probe overwrote the very payload the second read compares (lavapipe reports payloadAt=4096); reads through both mappings now precede writes through either, and the offset is searched for and reported; (b) an export failure on a handle type the driver never advertised as EXPORTABLE was classified FAIL instead of UNSUPPORTED (lavapipe's dma-buf answer). - Output is a RESULT/summary table carrying the raw driver verdicts (VkResult names, errno, GL enums) because those codes -- not a pass/fail bit -- are what §8.3 needs in order to pick the tier. - Built with NDK 27.3.13750724 for arm64-v8a / android-30, RelWithDebInfo, PIE, warning-clean; host build clang/RelWithDebInfo, warning-clean.	2026-09-05 20:50:04 -04:00
swung0x48	8a239177ac	[Feat] (Build, TraceApp): ship and exec a second native binary on android ... - PLAN-B.md §11 P0 lists spike A (the Android delivery chain) as a P0 deliverable, inherited verbatim from PLAN.md §15 P0; §8.1 inherits PLAN.md §11.1-§11.6, whose Android path needs a second process. Android gives an application no writable exec-able directory, so the only supported route is to name the binary lib*.so, let the packager put it in lib/<abi>/, and exec it out of getApplicationInfo().nativeLibraryDir. This builds that route end to end so the spike can be answered with evidence instead of folklore. - New root option MOBILEGL_BUILD_SERVER_SPIKE (OFF, ANDROID-only) adds the MobileGLServer target from tools/spikes/server_stub/main.cpp with PREFIX "lib" / SUFFIX ".so" and -fPIE/-pie: an .so name does not exempt the file from Android's PIE requirement. Its RUNTIME_OUTPUT_DIRECTORY is pointed at CMAKE_LIBRARY_OUTPUT_DIRECTORY, because AGP packages what lands in the per-ABI library output directory and CMake would otherwise put an executable elsewhere. - The option is opt-in on both sides. The plugin flavour cannot turn it on at all, and the trace flavour builds it only when asked, with `-Pmobilegl.buildServerSpike=ON` or MOBILEGL_BUILD_SERVER_SPIKE=ON in the environment; a flavour that silently carries an executable nothing loads is the kind of thing nobody notices until it ships. Verified both ways: assembleTraceDebug -Pmobilegl.buildServerSpike=ON packages lib/arm64-v8a/libMobileGLServer.so and `file` reports "ELF 64-bit LSB pie executable, ARM aarch64 ... interpreter /system/bin/linker64, for Android 26"; the same task with no property packages only libMobileGL.so and libtrace_replay_runner.so. - The stub prints one line to stdout and writes the same line to the file named by argv[1], then exits 0. The line carries pid/ppid/uid/gid and, decisively, the child's own /proc/self/attr/current: only `u:r:untrusted_app:...` proves an ordinary app process did the exec. An `adb run-as` shell runs in a different SELinux domain, so a success there would prove nothing. - RunSpawnSpike() starts the stub with argv [serverPath, markerPath], redirects the child's stdout/stderr into a captured file (an app process has stdout on /dev/null, so a printed line would otherwise vanish), waits for it, and reports exit status, signal, the exec errno, the parent's own SELinux context, the marker content and the captured stdout - to logcat, to the returned string, and to a <marker>.report file, because the Activity finishes immediately afterwards. - The child reports the errno of a REFUSED execve through a close-on-exec pipe. Without it the one datum the spike exists to produce is lost: the parent only ever sees a wait status, in which every reason has already been flattened into one exit code, and EACCES (SELinux, or a noexec mount) versus ENOEXEC (a packager that mangled the file) are opposite verdicts for the design. A successful exec closes the write end for free, so the parent reads EOF and reports execErrno=0. - fork/execve only. The earlier draft also carried a posix_spawn arm behind `__ANDROID_API__ >= 28`, which was dead code in every configuration this repo can build - bionic declares posix_spawn from API 28 and the root CMakeLists.txt pins MOBILEGL_ANDROID_API_LEVEL to 26 and refuses to configure lower - and would have silently become the production path, untested, on a minSdk bump. Keeping the arm that actually ships means the spike measures the code the server would really use. Nothing happens between fork and execve except open/dup2/execve/write/_exit, all async-signal-safe, because the parent is a multi-threaded JVM process. - The spike lives in its own TU, spawn_spike.cpp/.hpp, listed only by the trace APK's CMakeLists. Its sibling trace_replay_core.cpp is compiled verbatim by the DESKTOP mobilegl_trace_replay runner (tools/trace_replay/CMakeLists.txt names the same file), where <android/log.h> does not exist, so nothing Android-only may live there; spawn_spike.cpp carries an #error for anyone who adds it to that list. - The Activity runs the spike, and nothing else, when launched with the `mobilegl_spike_spawn` intent extra; that mode needs no trace, no golden and no render surface. It is a separate JNI entry point rather than another parameter on the 30-argument replay call, which it shares nothing with. - Not yet run on a device: both device locks are held by another campaign. The on-device verdict is the coordinator's step.	2026-09-05 20:49:57 -04:00