ThreeDS2Service.INSTANCE.getSDKVersion() crash

[mikkoville]

Describe the bug We recently updated Adyen sdk from 2.2.15 to 2.2.21

After the updated we have received some crash reports coming from ThreeDS2Service.INSTANCE.getSDKVersion().

Here is the stacktrace

Fatal Exception: java.lang.ExceptionInInitializerError:
       at com.adyen.threeds2.ThreeDS2Service.<clinit>(:45)

used by java.lang.RuntimeException: java.nio.file.NoSuchFileException: /data/app/~~uvDuXQxAbdDUVbh2X5bbbg==/com.xxx.xxx-MLX4eCf7qcFSjK9tw7VTQQ==/base.apk
       at atd.a.getMessageVersion.<clinit>(getMessageVersion.java:43)
       at atd.a.ChallengeResultError.<clinit>(:26)
       at com.adyen.threeds2.ThreeDS2Service.<clinit>(:45)

Note that we are calling ThreeDS2Service.INSTANCE.getSDKVersion() before we call initialize() on the same INSTANCE.

Is it so that we cannot get the sdk version safely anymore before calling the initialize() first?

To Reproduce Have not been able to reproduce yet locally. We have only under 20 crashes mostly coming from Samsung & Xiamoi devices

Expected behavior We want to be able to retrieve the sdk version statically at any time without crashing

Smartphone (please complete the following information):

• Device: Samsung galaxy s23, s24. Pixel4a
• OS: 13, 14

Additional context Add any other context about the problem here.

[tkuntubayev]

Hi @mikkoville, Thank you for bringing this to our attention.

The getSDKVersion() method should be accessible at any time without needing to call initialize() first, so this behavior is indeed unexpected. The ExceptionInInitializerError and NoSuchFileException you encountered suggest that certain files may not be loading correctly in some device or app states, which could be causing this issue. Unfortunately, I haven’t been able to reproduce it on my end so far.

In the meantime, as an alternative to getSDKVersion(), you can access the SDK version via BuildConfig.VERSION_NAME from the com.adyen.threeds2 package.

To help us investigate further, could you share any additional details, such as:

• Whether your app uses a cross-platform framework (e.g., Flutter, React Native) or native Android development
• If the app is obfuscated, and which obfuscation tool is in use
• Whether the app was in the background or foreground during the crash
• Which Android component (Activity, Service) calls this method, and its lifecycle state at the time
• Whether this method is called at app startup or during app use
• Whether the observed devices are modified/rooted
• Any device-specific conditions (e.g., low memory or low battery) at the time of the crash
• Any other observations you think may be relevant

This information will help us identify the issue more effectively.

Thank you for your patience as we work on this. We’ll keep this thread updated with our progress and any potential fixes.

[mikkoville]

Whether your app uses a cross-platform framework (e.g., Flutter, React Native) or native Android development

Native Android

If the app is obfuscated, and which obfuscation tool is in use

Stock R8. Android gradle plugin 8.7.1

Whether the app was in the background or foreground during the crash

Foreground

Which Android component (Activity, Service) calls this method, and its lifecycle state at the time

Android Activity running after onResume()

Whether this method is called at app startup or during app use

During app use

Whether the observed devices are modified/rooted

No

Any device-specific conditions (e.g., low memory or low battery) at the time of the crash

No

Any other observations you think may be relevant

Not at the moment

In the meantime, as an alternative to getSDKVersion(), you can access the SDK version via BuildConfig.VERSION_NAME from the com.adyen.threeds2 package.

Thanks for the tip 👍