Mobile Application Shielding for Android Version 7.2.0 (February 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.

The App Shielding feature to comply with China’s Personal Information Protection Law, PIPL, has been extended. For applications with a single-activity architecture, the consent activity can be disabled while integrators are still able to notify App Shielding of granted consent through the SDK. Enable the PIPL Support without Consent Activity configuration option to use this feature extension.

For more information about complying with PIPL, see Integrate App Shielding for app distribution in China.

App Shielding now supports APK signature scheme v3 and v3.1. APKs targeting a minSdk of Android 9 (API level 28) or later are signed with a v3 signing block. When Android App Bundles (AABs) are uploaded to Google Play, they are split into multiple APKs. Among these, at least one APK with a minSdk of Android 9 or later is generated and signed with a v3 signing block instead of a v2 signing block.

Some Android libraries use reflection to find the implementation of an interface by taking the interface name and appending the string "_Impl". The Shielding Tool can now correctly obfuscate those class and interface names by first randomly renaming the interface name and then setting the class name to a matching name. For example, MyInterface and MyInterface_Impl might be obfuscated to a and a_Impl.

An issue existed when the Shielding Tool needed to parse a specific byte code instruction that may be in an app that was compiled for a minSdk of 26 or newer. The Shielding Tool previously exited with an error like the following:

ERROR: Error: java.lang.RuntimeException: Unable to parse line 40 from classes.dex/com.example.Test:
invoke-custom {p0}, call_site_0("run", ...)@...Ljava/lang/invoke/CallSite;
...
Caused by: java.lang.IllegalArgumentException: Unknown primitive value type ()V
```

Status: This issue has been fixed.

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.

The ScreenMirroringData callback data in the ExtendedObserver interface adds an option to collect the display name of the first blocked screen. Use the getScreenMirroringDisplayName() method to retrieve the name. The sample included in the product package has been extended accordingly.

App Shielding can now detect more cases of rooted devices.

The detection of emulated input has been enhanced 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.

On some Android 5.x devices, App Shielding exited with an invalid option error. This was caused by App Shielding passing a flag to a libc function that was unknown to the old Linux Kernel of that Android version.

Status: This issue has been fixed.

A race condition in the libshield activity lifecycle listener could potentially cause an unexpected termination.

Status: This issue has been fixed.

App Shielding terminated unexpectedly when being awoken spuriously.

Status: This issue has been fixed.

A NullPointerException related to AccessibilityNodeInfo occurred on some Android versions while App Shielding blocked an untrusted screen reader.

Status: This issue has been fixed.

An Intent Receiver was leaking. The error may have been observed in an adb log message like the following:

```
...  1234  1234 E ActivityThread: Activity com.example.MyActivity has leaked IntentReceiver ab.C@12345678 that was originally registered here. Are you missing a call to unregisterReceiver()?
```

Status: This issue has been fixed.

An unexpected stack overflow  termination on executing onTransact was observed on several Huawei devices when running a shielded application

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.

Known limitations

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.