A historical Flutter WebRTC release-only class lookup failure

A release build can exercise shrinking and native lookup differently from a debug build. The earlier flutter_webrtc note recorded:

#
# Fatal error in: webrtc-source/sdk/android/src/jni/jni_generator_helper.cc, line 28
# last system error: 88
# Check failed: !clazz.is_null()
# org/webrtc/WebRtcClassLoader

Its workaround retained both the plugin and WebRTC classes:

## Flutter WebRTC
-keep class com.cloudwebrtc.webrtc.** { *; }
-keep class org.webrtc.** { *; }

The release build configuration then selected the rule file:

buildTypes {
    debug {
        debuggable true
        signingConfig signingConfigs.debug
    }
    release {
        debuggable false
        minifyEnabled true
        useProguard true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.release
    }
}

These broad keep rules and the older useProguard option belong to the original toolchain. They do not prove the root cause of every JNI lookup failure or that every retained class is necessary. The build-machine path has been generalized.

Source: earlier WebRTC example. No Android build or call was run for this revision.

← Back to the garden