Version 7.0.3 (January 2025)

The Android minimum supported version is 5.0 (API level 21). This version of App Shielding supports Android 15.

If you want your protected app to run on Android 15, you must upgrade to App Shielding 6.6.0 or later.

Beginning with Android 15, Android supports devices that are configured to use a page size of 16 KB (i.e., 16 KB devices). App Shielding has been updated to work on these 16 KB devices. However, if your app uses any native libraries, you must ensure that these libraries are ready for 16 KB page sizes. For more information, refer to the Android Developer documentation.

Some devices are rather slow on enabling accessibility services (e.g., Talkback). If a trusted screen reader is enabled  while a protected application is running, and enabling that screen reader takes a long time, App Shielding failed to see the enabled trusted screen reader and thus did not unblock the application for screen reader access.

Status: The initial fix for this, introduced in App Shielding version 7.0.1, has been refined to address rare edge cases.

We enhanced the detection of emulated input with improved scoring algorithms for specific Huawei, Oppo, and Realme devices.

Newer Java/Kotlin compilers now compile some Java code into byte code instructions like invoke-XX/range {} with an empty register range, instead of using invoke-XX. This caused the Shielding Tool to exit with an error message like the following:

ERROR: Error: java.lang.RuntimeException: Unable to parse line 154 from classes.dex/com.example.Test:   invoke-static/range {}, Lcom/invoke/TestCase;->aMethod()I
java.lang.Error: java.lang.RuntimeException: java.lang.RuntimeException: Unable to parse line 154 from classes.dex/com.example.Test:   invoke-static/range {}, Lcom/invoke/TestCase;->aMethod()I
at ...

Status: This issue has been fixed.

LeakCanary is a memory leak detection library for Android. An issue in the LeakCanary tool triggers an ANR in the Application-Lifecycle-Listener's onPause method.

Status: This issue has been fixed. App Shielding was modified to move resource allocation to some other time, which both improves runtime performance and avoids the ANR with LeakCanary.

In some cases, a protected application observed a deadlock. The corresponding adb log showed that the deadlock happened while some JNIEnv functions were trying to acquire a lock. Two possible cases were identified and fixed:

1. (SHAND-4669): Fixed signal handling while calling JNIEnv::NewLocalRef() or JNIEnv::FindClass(). Calling FindClass() in particular might result in more complex Java byte code execution. That is, initializing the class if it was not yet initialized.

2. (SHAND-4707): Removed @FastNative from some of the native Java methods of App Shielding. The annotation might help to make the application faster, though its documentation has the following "deadlock warning":

     > Deadlock Warning: As a rule of thumb, any native locks acquired in a

     > @FastNative call ([...]) must be released before returning to managed

     > code. Say some code does: fast_jni_call_to_grab_a_lock();

     > `does_some_java_work();` fast_jni_call_to_release_a_lock(); This code

     > can lead to deadlocks.

   To avoid the risk of a deadlock, the @FastNative annotation was removed from some internal native Java methods of App Shielding.

Description: Because of the nature of pure Javascript frameworks such as Cordova, the effectiveness of the push and pull bindings of App Shielding is affected. As a result, it might be possible to extract all Javascript files from a shielded application and build a new Cordova-based application with the extracted Javascript files. That new application will behave identical to the original one but has two major differences:

1. It is not longer protected with App Shielding.

2. It is signed with a different developer certificate.

Because this new application is signed with a different developer certificate, it is recognized by the stores or every device as a completely different and new application in comparison to the original shielded application. It cannot be avoided that a new application like this is built that looks and behaves similar to the original application.

OneSpan risk assessment: Threat actors will need to make heavy use of targeted phishing attacks to convince users of the original application to install the rogue version. For attackers, however, it is much easier to use existing malware frameworks that mimic hundreds of login screens in one single piece of malware. In addition, the existence of any rogue versions of the application does not affect the security features of the original shielded application. Everyone who is using the genuine, shielded application is protected with all the features of App Shielding, including all security measures of the original application. Therefore, we consider this issue to be of low risk.