Repository navigation
Android port, piece 2: the app opens the start screen, with Android's folder picker - #612
Merged
Merged
Conversation
The Android app from mamcjr's LASRecompAndroid (MIT), on top of the moving guest window: it builds with the NDK and opens the start screen. The game can't run yet (on-device game code build, movies, game files, touch and per-GPU Vulkan settings are the next pieces). - android/: Gradle + CMake app (libmain.so = the runtime, Vulkan backend and UI), SDL's activity, our own icon; android/deps/build_deps.sh builds SDL3, shaderc, volk and the Vulkan headers for arm64 from pinned sources. - runtime/platform/linux.c builds for Android: log to logcat and lasrecomp.log, data folder and resources from the app, unwinder backtraces, no re-exec, device info in the log. - runtime/main.c: on Linux the moving window can take a free spot from /proc/self/maps (an app process can't re-exec for another layout). - Vulkan on Android through volk (the loader exports 1.1 only before API 33), the swapchain left unrotated (the compositor turns it), always full screen. FFmpeg left out for now (the start screen's background frame). - apple_trees.c: kill() renamed (Bionic's signal.h declares one); Bionic's CPU_SET is a statement, so no comma forms in linux.c. - CI: an Android job builds the APK and fails if it holds anything but the runtime, SDL, shaderc and the shipped fonts and icon. - docs/android.md. Tested: the APK on an arm64 Android 15 emulator (Vulkan 1.3 on the Mac's GPU) opens the start screen, touch works, lasrecomp.log is written in the data folder; the macOS build plays as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…round Android destroys the window's surface when another activity covers the app (the folder picker, the home screen) and SDL makes a new one on return; the old VkSurfaceKHR stays lost, so every acquire failed and the screen stayed black. Each swapchain rebuild there now makes the surface again from SDL's current window, and a lost surface (acquire or present) triggers it; with no window yet, the frame is skipped. Tested on the arm64 Android 15 emulator: Home and back, and the folder picker, return to a drawn start screen. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SDL has no folder dialog on Android (Choose... showed the Linux message about xdg-desktop-portal). Choose... now opens the system folder picker (the activity, ACTION_OPEN_DOCUMENT_TREE), and Set Up copies exefs and romfs from the picked folder through the storage framework into the data folder - found as find_game does, with progress and cancel - then checks and builds as on the desktop. The Data folder row is fixed to the app's folder there. Tested on the arm64 Android 15 emulator: picked Download/LASGameFiles, the copy found version 1.0.0 and all 3,836 romfs files; the build then stops as expected (the on-device game code builder is the next piece). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second step of bringing in mamcjr's LASRecompAndroid (MIT), on top of the moving guest window from #611. The Android app now builds and opens the start screen, and the game files can be picked and copied in. It can't play yet: building the game code on the device is the next piece. Nothing changes for the desktop builds.
The app (
android/)libmain.sois the runtime, the Vulkan backend and the UI, built withLARECOMP_DYN_BASE.android/deps/build_deps.shbuilds SDL3, shaderc, volk and the Vulkan headers for arm64 from pinned sources.docs/android.mdcovers building and running it in the emulator.Platform layer
runtime/platform/linux.cnow also builds for Android, guarded by__ANDROID__:lasrecomp.logruntime/main.c: on Linux the moving window can take a free spot from/proc/self/maps. An app process can't restart itself for another memory layout.Vulkan on Android
SUBOPTIMALby design. That is no longer logged as a failure.Game files on Android
find_gamefinds them, with progress and cancel. It then checks and builds as on the desktop.Small shared fixes
apple_trees.c:kill()renamed, since Bionic'ssignal.hdeclares one.CPU_SETis a statement, solinux.cno longer uses comma forms of it.CI
Tested
lasrecomp.logis written in the data folderDownload/LASGameFilescopied the 1.0.0 files (all 3,836 romfs files), then the build stopped as expected ("the game code builder is missing")🤖 Generated with Claude Code