[Feature] Provide docs on how to minify when using Stripe SDK

[ColtonIdle]

Is your feature request related to a problem? Please describe.

I am minifying my app (r8) and my apps dex file size according to apk analyzer is ~6MB after all is said and done, but Stripe takes up like 4.9MB. 🤯 The thing is that I use my own UI for stripe, and use a very minimal set of apis. (all i do is save credit cards to a user, and then use those credit cards to make a payment with my user) Yet even after tree shaking, something in stripe doesn't seem to allow itself to be removed.

Describe the solution you'd like

Are there any additional docs to take into account when using stripe? Or does the library have to be updated to allow itself to be tree-shaken properly?

[ColtonIdle]

It looks like everything boils down to a bunch of activities that are added to my AndroidManifest?

BUT I did try the tools node remove trick to get rid of like the 50 activities that are pulled in by Stripe, but no luck. my final release apk is still like 50% stripe UI (which again, i do not use)

[ColtonIdle]

I moved to just using

implementation("com.stripe:payments-core:20.9.0") implementation("com.stripe:payments-model:20.9.0") implementation("com.stripe:stripe-core:20.9.0")

instead of

implementation("com.stripe:stripe-android:20.9.0")

and now instead of 4.9MB taken up by stripe, there is only 2.6MB, but when my app is 4.3 and 2.6 is taken up by stripe something feels wrong.

any idea why proguard can't treeshake stripe "views" for example? I don't use ANY stripe views.

according to apk analyzer it's because of AddPaymentMethodActivity?

[brnunes-stripe]

Hi @ColtonIdle, thanks for the feedback! We're planning on taking a deeper look into reducing our libraries' sizes over the coming months. Meanwhile, I'll investigate if there's something we can do in the short term to support this specific use case of not using any of our views. To confirm, you're using only methods from the Stripe class?

[ColtonIdle]

We use these imports for just adding and removing cards in our app. Our backend actually does the charging and everything

import com.stripe.android.Stripe import com.stripe.android.core.StripeError

import com.stripe.android.CustomerSession import com.stripe.android.createPaymentMethod import com.stripe.android.PaymentConfiguration

import com.stripe.android.EphemeralKeyProvider import com.stripe.android.EphemeralKeyUpdateListener

import com.stripe.android.model.CardParams import com.stripe.android.model.PaymentMethod import com.stripe.android.model.PaymentMethodCreateParams

I wonder if <activity android:name="STRIPE ACTIVITY NAME HERE" tools:node="remove"/> would help? Do you think I need them @brnunes-stripe if I dont use any stripe activity explicitly?

[ColtonIdle]

but yeah. let me know if you want me to help test in anything related to shrinking the size. even if there are proguard rules. im more than happy to put them into testing internally in our company to see if the app breaks in some way.

[brnunes-stripe]

If you don't use them, it's safe to remove:

• AddPaymentMethodActivity
• PaymentMethodsActivity
• PaymentFlowActivity
• StripeGooglePayActivity
• GooglePayLauncherActivity
• GooglePayPaymentMethodLauncherActivity
• CollectBankAccountActivity

This should allow the views to also be stripped. Can you try that and let me know if it helps? I'll be moving them to a separate module so that they're not included in apps that don't need them.

[ColtonIdle]

AWESOME. I didn't know if safe to remove because (for example) i didn't know if I built my own add credit card flow, if certain cards would require additional verification and therefore itd start an activity (somehow). but it seems like thats not the case?

I'll remove them now and make a build to see if it reduces apk size!

[brnunes-stripe]

Right, some of the activities will still be kept, the ones that are needed for authentication. You can verify that by testing with a test card that requires 3DS authentication. Those that I listed are part of different integrations, so they can be safely removed in your specific case. They are also the ones that use our UI elements, like CardMultilineWidget, so those should also be removed now.

[ColtonIdle]

Oh interesting. Okay. I was just about to come here and ask "Are you sure I can't get rid of"

"com.stripe.android.view.AddPaymentMethodActivity" "com.stripe.android.view.PaymentMethodsActivity" "com.stripe.android.view.PaymentFlowActivity" "com.stripe.android.view.PaymentAuthWebViewActivity" "com.stripe.android.view.PaymentRelayActivity" "com.stripe.android.payments.StripeBrowserLauncherActivity" "com.stripe.android.payments.StripeBrowserProxyReturnActivity" "com.stripe.android.payments.core.authentication.threeds2.Stripe3ds2TransactionActivity" "com.stripe.android.googlepaylauncher.StripeGooglePayActivity" "com.stripe.android.googlepaylauncher.GooglePayLauncherActivity" "com.stripe.android.googlepaylauncher.GooglePayPaymentMethodLauncherActivity" "com.stripe.android.payments.paymentlauncher.PaymentLauncherConfirmationActivity" "com.stripe.android.payments.bankaccount.ui.CollectBankAccountActivity" "com.stripe.android.stripe3ds2.views.ChallengeActivity"

BUT I didn't know they are needed for 3DS auth. Thanks for teaching!

[ColtonIdle]

Not really relevant, butinteresting that ChallengeActivity doesn't allow itself to be removed

[ColtonIdle]

Hm. Can't remove two of the activities

/Users/cidle/dev/rollertoaster/app/src/main/AndroidManifest.xml:39: Error: AddPaymentMethodActivity must extend android.app.Activity [Instantiatable]
        <activity android:name="com.stripe.android.view.AddPaymentMethodActivity" tools:node="remove" />
                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/cidle/dev/rollertoaster/app/src/main/AndroidManifest.xml:41: Error: PaymentFlowActivity must extend android.app.Activity [Instantiatable]
        <activity android:name="com.stripe.android.view.PaymentFlowActivity" tools:node="remove" />
                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Explanation for issues of type "Instantiatable":
   Activities, services, broadcast receivers etc. registered in the manifest
   file (or for custom views, in a layout file) must be "instantiatable" by
   the system, which means that the class must be public, it must have an
   empty public constructor, and if it's an inner class, it must be a static
   inner class.

2 errors, 0 warnings

[ColtonIdle]

After removing all of the other activities except for those 2 above, there was no change in apk size 😦

More than happy to test any new dependencies you come up with that'll shrink this for use cases like mine. cheers

[brnunes-stripe]

Okay, I'll need to refactor our modules then to move those activities, so that they're not included in the dependencies for a use case like yours. This is the proper long term solution, I was hoping we'd be able to achieve that by manually removing, but it looks like that won't work. I'll start by moving the ones that should be most impactful. I'll keep this ticket open to track progress and update it over the coming weeks. Thanks for your patience, and for raising the issue.

[ColtonIdle]

Awesome. Looking forward to lowering my apk size!

[ColtonIdle]

@brnunes-stripe just as a heads up. I finally went around and tested 3ds cards as per your comment

"Right, some of the activities will still be kept, the ones that are needed for authentication. You can verify that by testing with a test card that requires 3DS authentication."

but the activities for 3ds auth never started. Not sure if you have docs for implementing our own credit card management instead of stripe UI, but most likely you do have those docs and I need to find them and implement with those docs 😅

[sandyscoffable]

I'm seeing the same issue. Our app was previously 3.9 MB, and having included Stripe Payments it's increased to 8 MB. I got a warning when uploading the app bundle to the dashboard. We also have a competitors SDK (in the original 3.9MB size).

We're not using Stripe payment sheet, we've got our own UI (but delegate to the SDK for 3DS etc). We also use the card entry widget, but that's it. We've got proguard enabled, using kotlin etc etc.

So +1 for spending some time making the SDK work with proguard, as clearly there are lots of unnecessary things getting pulled in by default.

[sandyscoffable]

implementation("com.stripe:payments-core:20.12.0")
implementation("com.stripe:payments-model:20.12.0")
implementation("com.stripe:stripe-core:20.12.0")

instead of

implementation("com.stripe:stripe-android:20.12.0")

does seem to help somewhat, but I hate this as it goes against the online documentation, and like I say, the tree shaking should be automatic.

[sandyscoffable]

Ok, some figures.

I was a bit wrong about our old app size, it was actually 3.79MB. Like I say, including stripe-android increased this to 8MB.

By instead including the sub modules, the app size is now 5.95MB. Not ideal but it'll have to do for now, until a solution presents itself.

[brnunes-stripe]

Hey @sandyscoffable, thanks for the feedback! I'll be working on this in Q4, will make sure that users that are only using methods from Stripe, or just the card collection UI are not including unnecessary classes from our SDK.

[jaynewstrom-stripe]

Hi @ColtonIdle we released a change to fix this! We now only include the minimal proguard rules, you should see a massive reduction in size if you use R8 by upgrading to the latest SDK version.

[ColtonIdle]

Moved onto another project so I can't test this out just yet but thanks for the update