The Climb 1 starts again: the dormant foveation diagnostic also stays out of CryEngine's monolithic libAndroidLauncher.so (#432, #449)

a8e01c01 skipped only libCryRender*; The Climb 1 has no separate renderer, so engine_lib() picked
libAndroidLauncher.so and the layer was still linked into it. Both reporters' zips (1.3.0 and a dev build with
a8e01c01) crash identically: SIGSEGV fault addr 0xf0 under CreateSystemInterface+320 right after Vulkan instance
setup. frame.adapter package revision 4 for com.crytek.climb marks existing builds for Update on Frame.

docs/PLAYBOOK.md

@@ -85,7 +85,7 @@ version is `catalog/triage.yaml` (used by `frameport test` / the Job screen); ke
 | A game from an AXRB download starts and stops at once (Steam shows Resume), no OBB on the Frame; or a SideQuest backup adds a second game named after an APK in its `obb/` folder (reddit 2026-10-11) | AXRB keeps its own PC builds in `AXRB/patched/<package>/*-axrb.apk` (OVRPort-converted for its runtime, no OBBs); the scan added them over the original `AXRB/<app id>/<binary id>/base.apk`. SideQuest's VR4 backup has Unreal's `VR4-Android-Shipping-arm64.apk` next to the OBBs | `quest_dump._axrb_patched` skips AXRB's patched copies; a rescan replaces entries made from them; AXRB downloads send every non-APK file next to `base.apk` (DLC, assets) and are named after the package; APKs inside another game's data folder are ignored; SideQuest backups are named after the package folder, not the backup time. docs/FAQ.md has both layouts |
 | Game hangs at start / never loads although its .obb files are right there: next to the APK, in an `obb` folder beside an `apk` folder inside a `<package>` folder, or a SideQuest backup (`<timestamp>_<versionCode>.apk`) (GitHub #85, #91) | No folder named after the package, so the folder-layout checks found nothing and no OBB was uploaded | `quest_dump.find_data` then looks for the files by name, `(main\|patch).<versionCode>.<package>.obb` (any case), in the APK's folder, its parent and up to 3 levels below each (folders with their own APKs are other games); prefers the folder and files of the APK's own versionCode, else the newest older, else any version. When that folder also holds other things (the APK itself, other games' OBBs), the library entry gets `data_files` and only those files are uploaded, counted and deleted with the game. Add the folder again |
 | CryEngine game: `Powered by CRYENGINE`, then SIGTRAP in `libAndroidLauncher.so` during `CreateSystemInterface`, before any OpenXR instance (GitHub #238, The Climb 666.0) | Installed without its OBB: the SideQuest backup has `apk/com.crytek.climb.apk` + `obb/main.com.crytek.climb.obb`, but the scan required a versionCode in the OBB name and skipped it. The reported backtrace's fatal-error call formats `Engine initialization failed: Open Engine Paks: Unable to find "engine" pak files (%s)` | `quest_dump.find_data` accepts `(main\|patch).<package>.obb` as well as numbered names, keeping the original filename. Update on Frame finds the previously skipped data; a rescan finds it too. Analysis version 12 recognizes monolithic CryEngine through `assets/game.cryproject`, Vulkan through `assets/system.cfg` (`r_Driver = vk`), and an expected OBB through the launcher's expansion-path format strings; a missing OBB now gets the existing `missing-obb` warning/finding. This fixes the original missing-content startup failure; the rendering failures below were found once the data was installed |
-| CryEngine game (The Climb 1/2) on FramePort 1.3.0: `Messagebox: cap: Engine initialization failed!  text:CrySystem initialization failed!` right after the renderer lists its Vulkan device extensions, then SIGSEGV in `CSystem::ShutDown` (GitHub #432/#449) | 1.3.0 links the dormant foveation diagnostic `libVkLayer_fdm_darken.so` into every arm64 game's engine library; in CryEngine's `libCryRenderVulkan.so` that stops CrySystem from starting. Bisected headless on the dev Frame: the new build runs once only its renderer is the unmodified one | `foveation.diagnostic_support` skips `libCryRender*` (Climb 2's private VrApi bridge still loads the layer); `frame.adapter` package revision 3 for both Climb games marks their builds for Update on Frame. Triage `cryengine-init-failed` |
+| CryEngine game (The Climb 1/2) on FramePort 1.3.0: `Messagebox: cap: Engine initialization failed!  text:CrySystem initialization failed!` right after the renderer lists its Vulkan device extensions, then SIGSEGV in `CSystem::ShutDown` (GitHub #432/#449). The Climb 1 (monolithic, no symbols): SIGSEGV fault addr 0xf0 under `CreateSystemInterface+320` in `libAndroidLauncher.so` right after `MESA: Using gralloc0 CrOS API`, or a hang at that line | 1.3.0 links the dormant foveation diagnostic `libVkLayer_fdm_darken.so` into every arm64 game's engine library; in CryEngine's `libCryRenderVulkan.so` that stops CrySystem from starting. Bisected headless on the dev Frame: the new build runs once only its renderer is the unmodified one | `foveation.diagnostic_support` skips `libCryRender*` and CryEngine's monolithic `libAndroidLauncher.so` (The Climb 1; Climb 2's private VrApi bridge still loads the layer); `frame.adapter` package revision 3 for Climb 2, 4 for The Climb 1 marks their builds for Update on Frame. Triage `cryengine-init-failed` |
 | QuestCraft: Minecraft never starts, `libjvm.so not found`; no `files/runtimes/` folder in the game's storage; the log shows `Transports: ETHERNET` (GitHub #18, #468) | pojlib's `API.hasConnection()` only counts Wi-Fi and Lepton's Android reports Ethernet, so the Java runtime download is skipped | `frame.pojlib_connection` makes `hasConnection()` return true (dex edit; catalog + QuestCraft's package, new scans by analysis field). Workaround: unpack QuestCraft's `JRE.zip` into `files/runtimes/JRE` with the Files tab. Triage `questcraft-no-java-runtime` |
 | Nothing starts, `APP_ACTIVITY is empty`, although the manifest has category LAUNCHER: it sits on an `<activity-alias>` (Flycast-based HOTD2 VR: `MainActivity` → `NativeGLActivity`, GitHub #400/#469) | Lepton only starts real activities | `frame.launcher` gives the alias's target activity its own MAIN/LAUNCHER intent-filter (the alias's categories; inserted after the activity's start element) and turns the alias's LAUNCHER into INFO (`axml.launcher_from_alias`); the validator's "Launchable in Lepton" check now requires a real activity |
 | A game shows UTC instead of local time (Walkabout Mini Golf's clock, GitHub #429); in the container `getprop persist.sys.timezone` = `../usr/share/zoneinfo/<Zone>` | Lepton sets the zone from a bare `readlink /etc/localtime` minus `/usr/share/zoneinfo/`, and SteamOS' link is relative | Lepton launchers put `~/.local/share/frameport/lepton-shims` first on PATH (agent `TZ_LINE`, `upgrade_launchers` adds it); its `readlink` answers `/etc/localtime` with the resolved path. Checked on the dev Frame: `America/New_York`, `date` in EDT. A boot property line from FramePort can't override it (Lepton writes its own line later) |

src/frameport/patches/frame/adapter.py

@@ -26,7 +26,7 @@ class FrameBridgeAdapter(Patch):
     id = "frame.adapter"
     # above revision 2: Batman builds before #389 are outdated; The Climb 1/2 builds with the diagnostic layer linked
     # into CryEngine's renderer don't start (#432/#449); AC Nexus builds before the Vulkan panel pool (#424)
-    package_revisions = {"com.camouflaj.manta": 3, "com.crytek.climb": 3, "com.crytek.climb2": 3,
+    package_revisions = {"com.camouflaj.manta": 3, "com.crytek.climb": 4, "com.crytek.climb2": 3,
                          "com.Ubisoft.ACNexusVR": 3}
     a32 = True  # also for 32-bit games on the bridge
     title = "FrameBridge OpenXR adapter"

src/frameport/patches/frame/foveation.py

@@ -20,7 +20,8 @@ LAYER = "libVkLayer_fdm_darken.so"
 BATMAN_ORIGINAL = "76cafa25c2243c2bc065e30d83d7083b8546153dc6a3c39227235fbabe13c969"
 CLIMB_RENDERER = "31a121dbfae692fdc0e54853e0640eed820f07826893fa0d905767c9620023a0"
 CLIMB_BRIDGE = "libvrapi_foveation.so"
-CRYENGINE_RENDERER = "libCryRender"
+# CryEngine: the modular renderer (Climb 2) and the monolithic launcher that contains it (The Climb 1)
+CRYENGINE_RENDERER = ("libCryRender", "libAndroidLauncher")
 STORAGE_WORDS = ((0x21c778, 0x5298000b, 0x5290000b),
                  (0x21c77c, 0x5288000c, 0x5280000c),
                  (0x21df50, 0x52980009, 0x52900009))
@@ -145,7 +146,8 @@ def diagnostic_support(ws):
     lib = engine_lib(ws) or "libopenxr_loader_generic.so"
     if lib.startswith(CRYENGINE_RENDERER):
         # Linked into CryEngine's renderer, The Climb 1/2 fail CrySystem initialization at start (GitHub #432/#449,
-        # headless on the dev Frame). Climb 2's private VrApi bridge loads the layer itself.
+        # headless on the dev Frame). Climb 2's private VrApi bridge loads the layer itself. The Climb 1 has no
+        # separate renderer: its whole engine is libAndroidLauncher.so, which engine_lib() picks.
         return False
     data = ws.read_lib(lib)
     changed = False

tests/test_foveation_preferences.py

@@ -217,7 +217,9 @@ def test_dormant_diagnostic_stays_out_of_cryengine_renderers(monkeypatch):
         def put(self, *a):
             self.written.append(a)
 
-    monkeypatch.setattr(foveation, "engine_lib", lambda ws: "libCryRenderVulkan.so")
-    ws = Ws()
-    assert foveation.diagnostic_support(ws) is False and not ws.written
+    for lib in ("libCryRenderVulkan.so", "libAndroidLauncher.so"):  # The Climb 2 / The Climb 1 (monolithic)
+        monkeypatch.setattr(foveation, "engine_lib", lambda ws, lib=lib: lib)
+        ws = Ws()
+        assert foveation.diagnostic_support(ws) is False and not ws.written
+    assert adapter.FrameBridgeAdapter().revision_for("com.crytek.climb") == 4
     assert adapter.FrameBridgeAdapter().revision_for("com.crytek.climb2") > adapter.FrameBridgeAdapter.revision