ksg97031/frida-gadget

The test suite verifies that the output APK is built correctly — the gadget lands in lib/<abi>/, the loadLibrary name matches the file, the config is generated, the APK signs and jarsigner verifies it. What none of it checks is the thing the tool exists to do: that the gadget actually loads on a device and frida can attach. That is the gap behind the hardest reports to act on — #17, #20 (Unity/Quest), #34 ("apps won't start") — where the APK is structurally fine but does not run. Those cannot be reproduced from the build output alone. reactivecircus/android-emulator-runner can run an emulator in Actions, which makes an end-to-end smoke test possible: inject into a small open-source APK (F-Droid has suitable ones with a normal dex, e.g. app.varlorg.unote) sign with --sign install on the emulator launch, then frida -U Gadget (or list processes) to confirm the gadget came up It is slow and occasionally flaky, so workflow_dispatch or a nightly schedule fits better than running on e

insert_load_library_call() handles one shape of method header: if ".locals" not in declaration: continue text[idx + 1] = declaration.replace(".locals 0", ".locals 1") text.insert(idx + 2, " invoke-static {v0}, Ljava/lang/System;->loadLibrary(...)V") text.insert(idx + 2, f' const-string v0, "{load_library_name}"') Two limits are visible in that code: Methods declared with .registers N instead of .locals N are skipped entirely. apktool emits .registers in some cases, and the search then falls through to the next entrypoint or gives up with "Cannot find the appropriate position in the main activity". Only .locals 0 is widened. Higher counts are left alone, which is fine as long as v0 is genuinely free at the top of the method, but nothing verifies that. There is a run of reports that look like this class of problem rather than anything specific to an app: #12 (invalid register), #21 (smali over register), #17, #20 and #34 (app does not start after injection). What would help m

tests/ has 93 tests covering the decompile target, the apktool command line, gadget naming and config, smali patching, password redaction, the signer's TTY handling and the dex restore — but no workflow runs them. The only workflows are contributors.yml and typos.yml, so a change that breaks the suite merges green. A minimal job: name: tests on: [push, pull_request] jobs: pytest: runs-on: ubuntu-latest strategy: matrix: python-version: ["3.9", "3.11", "3.13"] steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} - run: pip install -r requirements-dev.txt - run: python -m pytest tests/ -q The suite needs no apktool, no device and no network, so it runs in a few seconds. Worth adding pylint scripts/ tests/ and pydocstyle to the same job while it is there — both are currently clean (10.00/10 and zero), so they would start from a passing state.