Skip to content

fix(android): ship R8 keep rules for DocuSign's esign models - #15

Merged
IronTony merged 1 commit into
mainfrom
fix/android-r8-consumer-rules
Sep 29, 2026
Merged

IronTony merged 1 commit into
mainfrom
fix/android-r8-consumer-rules

Conversation

@IronTony

Copy link
Copy Markdown
Owner

Ships R8 keep rules with the module, so an app that turns on minification keeps DocuSign login and captive signing working without adding rules of its own. Released as 2.0.1.

Why

  • DocuSign's androidsdk-2.1.7.aar ships consumer rules that keep com.docusign.androidsdk.** only.
  • The Gson models live in sdk-esign-api-2.1.7.jar (com.docusign.esign.model, 580 classes), a plain JAR with no META-INF/proguard rules. The SDK names them only in generic signatures, so R8 finds no use and removes all of them. Login and captive signing then fail at runtime, and nothing crashes at launch.
  • The module already pins the DocuSign SDK version and the sdk-pdf SHA, so the rule sits next to those pins. Consuming apps get it through consumerProguardFiles with no setup.

Changes

  • android/consumer-rules.pro (new): keeps com.docusign.esign.model.** { *; }. Keeping all of com.docusign.esign.** fails R8 on the missing org.apache.oltu classes the esign client references, so the rule covers the models only. It also has -keepnames class expo.modules.docusign.**, so DocuSignError.native.domain stays readable in an obfuscated build.
  • android/build.gradle: consumerProguardFiles 'consumer-rules.pro' in defaultConfig.
  • package.json, package-lock.json: 2.0.1.
  • CHANGELOG.md: a 2.0.1 Fixes entry.
  • README.md: a "Minified release builds (R8)" section after the Glide workaround.

The module's own Kotlin needs no rules. Error codes are explicit, expo-modules-core's consumer rules keep the Records, the recipient-view request uses JSONObject, and the JS network classifier matches java.net.* names, which R8 never renames.

Verification

  • Lint, build and all 101 Jest tests pass. npm pack includes android/consumer-rules.pro.
  • An Expo SDK 57 app with enableMinifyInReleaseBuilds, built with ./gradlew :app:assembleRelease (arm64):
2.0.0 2.0.1
Rule in merged configuration.txt no yes
com.docusign.esign.model classes in dex 0 of 580 580 of 580
ViewUrl.url gone present
APK 24.4 MB 25.1 MB
  • Pre-push review returned Ship on 17babf5 with no blocking findings. Its one follow-up is the device run below, which would back the README's claim that apps need no DocuSign keep rules of their own.
  • Not run: login and captive signing on a device with a minified build. The dex check shows the classes and fields survive. It does not exercise Gson at runtime.

Notes

  • Running ./gradlew assembleRelease from the root of a consuming app fails in :react-native-docusign:bundleReleaseAar, because AGP rejects the local sdk-pdf .aar when it bundles a library AAR. This predates 2.0.1. :app:assembleRelease and EAS builds are unaffected.
  • The 0.6 MB is the cost of keeping the whole model package. Narrowing it to the models the SDK references today would need re-checking on every SDK bump.

DocuSign's androidsdk AAR ships consumer rules for com.docusign.androidsdk
only. The Gson models in sdk-esign-api are named in generic signatures but
never used directly, so R8 removes them. An app with minification on lost
login and captive signing at runtime, with no crash at launch.

android/consumer-rules.pro keeps com.docusign.esign.model.** and the
module's class names, and consumerProguardFiles applies it in every
consuming app.

In an Expo SDK 57 app with enableMinifyInReleaseBuilds, the 2.0.0 release
APK kept 0 of the 580 model classes. With the packed 2.0.1 the rule is in
the merged R8 configuration, all 580 classes and ViewUrl.url survive, and
the APK grows by 0.6 MB.
@IronTony IronTony self-assigned this Sep 29, 2026
@IronTony IronTony added the enhancement New feature or request label Sep 29, 2026
@IronTony
IronTony merged commit 3196c83 into main Sep 29, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant