feat(mobile): add the App Store 4.7 self-audit, a release build path, and a UniFFI smoke test #332
There are no files selected for viewing
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
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
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
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,107 @@ | ||
| package com.doublegate.rustysnes | ||
|
|
||
| import androidx.test.ext.junit.runners.AndroidJUnit4 | ||
| import androidx.test.platform.app.InstrumentationRegistry | ||
| import org.junit.Assert.assertEquals | ||
| import org.junit.Assert.assertFalse | ||
| import org.junit.Assert.assertTrue | ||
| import org.junit.Test | ||
| import org.junit.runner.RunWith | ||
| import uniffi.rustysnes_mobile.MobileCore | ||
| import uniffi.rustysnes_mobile.MobileRegion | ||
|
|
||
| /** | ||
| * The UniFFI smoke test: proves the generated Kotlin bindings actually **load and call** the native | ||
| * library on a real Android runtime. | ||
| * | ||
| * `assembleDebug` already proves the bindings *compile* against the shell — `MainActivity` calls | ||
| * `MobileCore` directly, so a bindgen output that drifted from the Rust API fails the Kotlin | ||
| * compile. What a build cannot prove is that `System.loadLibrary` finds the `.so` for the device's | ||
| * ABI, that JNA's mapping matches the symbols in it, and that a call marshals across and returns. | ||
| * Those are runtime facts, and this project has already shipped one native Android crash that a | ||
| * build could not have caught. | ||
| * | ||
| * Deliberately ROM-free. The app takes ROMs only from the user's document picker | ||
| * (`docs/app-store-4-7-self-audit.md`), so there is no ROM to open here and no need for one: every | ||
| * assertion below is about the *bridge*, not about emulation, which the workspace's own test suite | ||
| * covers far better than an emulator can. | ||
| */ | ||
| @RunWith(AndroidJUnit4::class) | ||
| class MobileCoreSmokeTest { | ||
| /** Constructing the core loads the library and crosses the FFI boundary once. */ | ||
| @Test | ||
| fun the_native_library_loads_and_a_core_can_be_constructed() { | ||
| val core = MobileCore(MobileRegion.NTSC) | ||
| assertFalse("a freshly constructed core must report no ROM loaded", core.romLoaded()) | ||
| } | ||
|
|
||
| /** | ||
| * A frame with no ROM loaded still has to return a correctly sized framebuffer. This is the | ||
| * assertion that would catch a marshalling error: a wrong length, or a returned buffer that | ||
| * does not survive the crossing, shows up here and nowhere in a build. | ||
| */ | ||
| @Test | ||
| fun a_frame_runs_and_returns_a_framebuffer_of_the_declared_size() { | ||
| val core = MobileCore(MobileRegion.NTSC) | ||
| core.runFrame() | ||
|
|
||
| val size = core.frameSize() | ||
| assertTrue("frame width must be positive, got ${size.width}", size.width > 0u) | ||
| assertTrue("frame height must be positive, got ${size.height}", size.height > 0u) | ||
|
|
||
| val fb = core.framebuffer() | ||
| assertEquals( | ||
| "the framebuffer length must be width * height * 4 (RGBA8)", | ||
| (size.width * size.height * 4u).toInt(), | ||
| fb.size, | ||
| ) | ||
| } | ||
|
|
||
| /** AccuracySNES's HiROM image, packaged as a test asset by Gradle's `copyTestRom`. */ | ||
| private fun testRom(): ByteArray = | ||
| InstrumentationRegistry.getInstrumentation().context.assets | ||
| .open("accuracysnes-hirom.sfc").use { it.readBytes() } | ||
|
|
||
| /** | ||
| * A **real cart boots on the device**, and only then is the audio buffer asserted. | ||
| * | ||
| * This test took two wrong turns, both of the same kind. It first asserted that two successive | ||
| * `drainAudio()` calls return equal counts, claiming to pin the documented non-destructive | ||
| * contract; then that the buffer length is even, claiming to pin interleaved stereo. A no-ROM | ||
| * frame produces **no audio at all** (measured on the host: `first=0 second=0`), so the first | ||
| * passed on `0 == 0` and the second on `0 % 2 == 0`. Neither could fail for the reason it named. | ||
| * | ||
| * The fix is not a better assertion, it is a cart. `docs/mobile-readiness.md` records that no | ||
| * ROM had ever actually booted on a device or simulator; loading one here closes that and makes | ||
| * every assertion below capable of failing. | ||
| */ | ||
| @Test | ||
| fun a_real_cart_boots_and_produces_audio() { | ||
| val core = MobileCore(MobileRegion.NTSC) | ||
| core.loadRom(testRom()) | ||
| assertTrue("the cart did not load", core.romLoaded()) | ||
|
|
||
| // Eight frames for margin, not because eight are needed: measured on the host, a booted | ||
| // AccuracySNES cart emits 1066 interleaved samples from the FIRST frame. Stating that | ||
| // rather than a plausible "the APU needs the IPL handshake first" — which the measurement | ||
| // disproves — keeps the comment something a reader can rely on. | ||
| repeat(8) { core.runFrame() } | ||
|
|
||
| val audio = core.drainAudio() | ||
| assertTrue("a booted cart produced no audio at all", audio.isNotEmpty()) | ||
| assertEquals( | ||
| "drainAudio must return interleaved stereo, so its length is always even", | ||
| 0, | ||
| audio.size % 2, | ||
| ) | ||
| } | ||
|
coderabbitai[bot] marked this conversation as resolved.
|
||
|
|
||
| /** Reset and power-cycle are the two lifecycle calls the shell makes; both must cross safely. */ | ||
| @Test | ||
| fun the_lifecycle_calls_cross_the_boundary() { | ||
| val core = MobileCore(MobileRegion.NTSC) | ||
| core.reset() | ||
| core.powerCycle() | ||
| assertFalse("no ROM was ever loaded", core.romLoaded()) | ||
| } | ||
| } | ||
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: doublegate/RustySNES
Length of output: 19756
🏁 Script executed:
Repository: doublegate/RustySNES
Length of output: 37135
🌐 Web query:
Android 16 KB page sizes APK ZIP alignment zipalign -P 16 official documentation💡 Result:
To ensure your application is compatible with 16 KB page size requirements, you must perform two distinct types of alignment: aligning the ELF segments of your native libraries (.so files) and ZIP-aligning your APK [1][2]. Starting November 1, 2025, all new apps and updates submitted to Google Play that target Android 15 and higher must support 16 KB page sizes [1]. 1. ELF Alignment Native libraries must be built with 16 KB segment alignment. This is achieved at compile-time by passing linker flags to the NDK [3]. When building your libraries, use the following linker flags: -Wl,-z,max-page-size=16384 You can verify the alignment of your.so files using tools like readelf or objdump to ensure the LOAD segments are aligned to 16 KB (0x4000) [3][4]. 2. APK ZIP Alignment Once your libraries are correctly built, you must use the zipalign tool to align the uncompressed native libraries within the APK to 16 KB boundaries [1][5]. This ensures the files can be memory-mapped (mmap) efficiently by the Android system [5]. Use the following zipalign command: zipalign -v -P 16 -f 4 APK_NAME.apk OUTPUT_NAME.apk In this command: -P 16: Specifies that uncompressed.so files should be aligned to a 16 KiB page boundary [5]. -f: Overwrites the existing output file if necessary [5]. -v: Provides verbose output to confirm the alignment process [5]. -c: (Optional) Can be used to check the alignment of an existing APK without modifying it [1][5]. The official Android documentation confirms that using -P 16 is the recommended approach to ensure compatibility with both 16 KB and 4 KB page size devices [5]. If you do not perform these steps, your app may fail compatibility checks or trigger warnings in the Google Play Console [6][2].
Citations:
🏁 Script executed:
Repository: doublegate/RustySNES
Length of output: 358
🌐 Web query:
site:developer.android.com/guide/practices/page-sizes AGP 8.5.1 16 KB zip alignment💡 Result:
Android Gradle Plugin (AGP) version 8.5.1 and higher is required to properly support 16 KB page size alignment for apps that use uncompressed shared libraries [1]. Key technical details regarding this requirement include: 1. Requirement for 16 KB Alignment: Devices using 16 KB page sizes require that uncompressed shared libraries (.so files) shipped within an app are aligned on a 16 KB zip-aligned boundary to function correctly [1]. 2. Why AGP 8.5.1 is Necessary: While AGP versions 8.3 through 8.5 align apps to 16 KB by default, they do not always ensure that bundletool zip-aligns the resulting APKs correctly when built from an Android App Bundle (AAB) [1]. Upgrading to AGP 8.5.1 or higher ensures this alignment is handled correctly during the build process, preventing potential installation failures on 16 KB devices [1]. 3. Alternative for Older AGP Versions: If upgrading to AGP 8.5.1+ is not possible, developers must configure their Gradle build to use compressed shared libraries [1]. However, this is discouraged because compressed libraries must be extracted to disk during installation, which increases the app's installation footprint and can lead to more frequent installation failures due to insufficient disk space [1]. 4. Compatibility Recommendation: To ensure 16 KB compatibility, the official recommendation is to update tools to the latest versions, specifically AGP 8.5.1 or higher and NDK version r28 or higher, and ensure all prebuilt dependencies are also 16 KB compatible [1].
Citations:
Add a 16 KB ZIP-alignment check for the release APK.
This step checks ELF
LOADalignment only. An APK with aligned ELF segments but a 4 KB-aligned uncompressed.soZIP entry passes this step and fails 16 KB compatibility checks. Runzipalign -c -P 16 -v 4 "$apk"before extraction.🤖 Prompt for AI Agents