[AlexCernik]

When using React Native 0.87 with AGP 9 and R8/ProGuard enabled, the app can crash on startup with the following error:

Wrong configuration of external resource loader:
java.lang.AssertionError:
Class net.time4j.android.spi.AndroidResourceLoader has no zero argument constructor

This was not reproducible with React Native 0.86.2 and NDK 27.

This PR updates the ProGuard documentation with the rules required to prevent R8 from removing the zero-argument constructor used by Time4J:

-keep public class net.time4j.android.ApplicationStarter
-keep public class net.time4j.PrettyTime
-keep public class net.time4j.android.spi.AndroidResourceLoader {
    public <init>();
}

[olitynskyi-mtb]

-keep public class net.time4j.android.ApplicationStarter { *; }
-keep public class net.time4j.PrettyTime { *; }
-keep class net.time4j.android.spi.AndroidResourceLoader {
    public <init>();
}

[huhu415]

Confirmed the same underlying crash with React Native 0.88.0 / Expo 58.0.14 and react-native-date-picker 5.0.13.

Environment: AGP 9.2.1, Gradle 9.4.1, New Architecture enabled, Android arm64, release minification and resource shrinking enabled. The library's getDefaultProguardFile call was locally patched to use proguard-android-optimize.txt for AGP 9 compatibility.

The JS error was misleading: importing the picker reported react-native-date-picker is not installed correctly. Loading the affected release APK in an isolated Android instrumentation harness exposed the underlying failure:

java.lang.AssertionError: Wrong configuration of external resource loader:
java.lang.Class<net.time4j.android.spi.AndroidResourceLoader> has no zero argument constructor

The failure occurs during DatePickerModule construction. Direct reflection against the affected APK also confirmed a NoSuchMethodException for AndroidResourceLoader.<init>().

Adding just this targeted rule to the app's existing rules and rebuilding the minified release APK fixed that regression:

-keep class net.time4j.android.spi.AndroidResourceLoader {
    public <init>();
}

Using the same instrumentation harness, the rebuilt APK now exposes the public zero-argument constructor and successfully constructs DatePickerModule. The debug build also renders the picker and responds to wheel interaction normally.

Besides documenting the workaround, could this constructor rule be shipped as a consumer ProGuard rule in the library? That would protect downstream apps automatically. Preserving the original exception as the cause of the JS installation error would also make this much easier to diagnose.