A renamed JNI callback does not fail the build — it produces a release APK that aborts on the first callback of every test. That shipped once, because every on-device check used the debug build, which does not minify. This reads R8's own mapping file for the classes and callback methods, and the DEX string pool for the native entry points. Native methods are deliberately not checked against mapping.txt: R8 only emits entries for members with a body or a rename, so a native method is absent either way and absence would prove nothing. Verified by deleting the callback keep rules and rebuilding: the check reports MainThreadCallback renamed along with onOutput, onError and onComplete, which is exactly the failure that shipped — with no device involved. Also avoids `... | strings | grep -q` and dumps to a file first. Under `set -o pipefail`, grep -q exits at the first match and SIGPIPEs strings, so the pipeline reports failure for a name found early and success for one found late. It reported two of four names missing while all four were present. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
iperf3-gui
A Flutter-based Android GUI wrapper for iperf3, the popular network performance measurement tool.
Features
- Client-mode network throughput testing
- Configurable server, port, duration and parallel streams
- Live iperf3 output, streamed line by line while the test runs
- Stop a running test early
- Copy the transcript to the clipboard
- iperf3 3.19 compiled into the app as a native library — no external binary
Architecture
lib/
├── domain/
│ ├── models/ # TestConfiguration, Iperf3Result
├── data/
│ └── services/ # Iperf3Service (MethodChannel → JNI)
├── ui/
│ └── features/
│ └── test_run/ # TestRunScreen, TestRunViewModel
└── main.dart # App entry point
android/app/src/main/
├── kotlin/…/IperfRunner.kt # MethodChannel handler, runs tests off the platform thread
└── cpp/iperf_jni.c # JNI bridge into the iperf3 API
See docs/README.md for the data flow, the native API surface and the design decisions behind them.
Why JNI instead of executing a binary
Android SELinux in Enforcing mode blocks execve() from the untrusted_app
domain, so shipping an iperf3 ELF in assets and running it via Process.start()
fails with "Permission denied". iperf3 is therefore compiled as a shared library
(libiperf3jni.so) and called in-process over JNI.
assets/iperf3/ still holds the pre-compiled binaries from that earlier
approach. They are not declared in pubspec.yaml, so they are not packaged into
the APK, and nothing in the app reads them.
Building
Prerequisites:
- Flutter 3.47+
- Android SDK with platform android-36
- JDK 17
- NDK r28+ and CMake 3.22.1 (for the native build)
flutter pub get
flutter analyze
flutter test
flutter build apk --debug
adb install -r build/app/outputs/flutter-apk/app-debug.apk
Testing against a local server
iperf3 -s -p 5201 # on a machine on the same network
ip -4 addr show # note its address
Enter that address in the app, then press GO.
Dependencies
- Dart:
provider - Native: iperf3 3.19 + cJSON, built by CMake for
armeabi-v7aandarm64-v8a
License
MIT — bundled iperf3 3.19 is BSD-3-Clause licensed.