Summary
Loading a ROM via "Load ROM or ZIP" shows "Finding game data", then returns to the main screen. The load never completes. The app clears ROM_IDENTITY in about 1 ms, then emits no further stage events while allocating and freeing large amounts of heap.
Environment
App: DualDex 1.2.0, versionCode 1020099, package com.darkaxt.dualdex. Signer SHA-256 matches the pinned release cert C5A02CEC…8E3B2FBA. Device: AYN Thor (kalama), Android 13, aarch64. Heap limits: dalvik.vm.heapgrowthlimit=256m, dalvik.vm.heapsize=512m. All files access: MANAGE_EXTERNAL_STORAGE reports "allow", verified via appops and granted before the load attempt.
ROM
Pokemon SoulGold v1.0.4, an Emerald-based hack. Header verified valid: Game Title "POKEMON EMER", Game Code BPEE, Nintendo logo bytes an exact match (24 FF AE 51 69 9A A2 21 3D 84 82 0A), header checksum stored 0x72 equals computed 0x72. Size 33,554,432 bytes, i.e. 32 MB expanded, where Emerald is natively 16 MB. Stored on an exFAT SD card.
Observed telemetry
Per load attempt, DualDexPerf emits only three events: LOAD_STARTED, then CACHE_DECISION with cacheDecision=MISS_FILE_ABSENT, then STAGE_FINISHED with stage=ROM_IDENTITY and stageElapsedMillis of 0 to 1. No stage event follows.
Immediately after, there is sustained GC activity. Successive collections freed 90 MB, 93 MB, 170 MB, 124 MB and 151 MB, with the heap moving between 47 and 83 MB used against a 131 to 171 MB pool. An earlier attempt reported gcCount 281, gcTimeMillis 4267, and javaHeapUsedBytes 126031696 against javaHeapCommittedBytes 155583536.
No OutOfMemoryError and no lowmemorykiller entry appear in logcat. The process is not obviously killed; the UI simply returns to the main screen.
Guess at the cause
The 32 MB expanded size is the most conspicuous difference from a stock Emerald ROM, so a parser assuming 16 MB layout or offsets seems the likeliest culprit. That is speculation, not something I have confirmed.
Possibly relevant environment detail
ROMs are on the SD card while RetroArch's SaveRAM is on internal storage. The README describes the all-files grant as enabling discovery of "sibling GB/GBC/GBA folders and RetroArch SaveRAM", which may assume both live on one volume. Flagging in case discovery is involved.
Not yet retested
A smaller ROM also failed, but that attempt predated granting All files access, so it is not a valid data point. Happy to rerun it, or any other diagnostic you want.
Summary
Loading a ROM via "Load ROM or ZIP" shows "Finding game data", then returns to the main screen. The load never completes. The app clears ROM_IDENTITY in about 1 ms, then emits no further stage events while allocating and freeing large amounts of heap.
Environment
App: DualDex 1.2.0, versionCode 1020099, package com.darkaxt.dualdex. Signer SHA-256 matches the pinned release cert C5A02CEC…8E3B2FBA. Device: AYN Thor (kalama), Android 13, aarch64. Heap limits: dalvik.vm.heapgrowthlimit=256m, dalvik.vm.heapsize=512m. All files access: MANAGE_EXTERNAL_STORAGE reports "allow", verified via appops and granted before the load attempt.
ROM
Pokemon SoulGold v1.0.4, an Emerald-based hack. Header verified valid: Game Title "POKEMON EMER", Game Code BPEE, Nintendo logo bytes an exact match (24 FF AE 51 69 9A A2 21 3D 84 82 0A), header checksum stored 0x72 equals computed 0x72. Size 33,554,432 bytes, i.e. 32 MB expanded, where Emerald is natively 16 MB. Stored on an exFAT SD card.
Observed telemetry
Per load attempt, DualDexPerf emits only three events: LOAD_STARTED, then CACHE_DECISION with cacheDecision=MISS_FILE_ABSENT, then STAGE_FINISHED with stage=ROM_IDENTITY and stageElapsedMillis of 0 to 1. No stage event follows.
Immediately after, there is sustained GC activity. Successive collections freed 90 MB, 93 MB, 170 MB, 124 MB and 151 MB, with the heap moving between 47 and 83 MB used against a 131 to 171 MB pool. An earlier attempt reported gcCount 281, gcTimeMillis 4267, and javaHeapUsedBytes 126031696 against javaHeapCommittedBytes 155583536.
No OutOfMemoryError and no lowmemorykiller entry appear in logcat. The process is not obviously killed; the UI simply returns to the main screen.
Guess at the cause
The 32 MB expanded size is the most conspicuous difference from a stock Emerald ROM, so a parser assuming 16 MB layout or offsets seems the likeliest culprit. That is speculation, not something I have confirmed.
Possibly relevant environment detail
ROMs are on the SD card while RetroArch's SaveRAM is on internal storage. The README describes the all-files grant as enabling discovery of "sibling GB/GBC/GBA folders and RetroArch SaveRAM", which may assume both live on one volume. Flagging in case discovery is involved.
Not yet retested
A smaller ROM also failed, but that attempt predated granting All files access, so it is not a valid data point. Happy to rerun it, or any other diagnostic you want.