Mobile Application Shielding for Android Version 7.3.1 (April 2025)

This version of App Shielding improves the startup and runtime performance of a protected application with the following measures:

• Reduced number of concurrently running threads.

• Optimized algorithms.

• Lowered thread priority for background threads on low end devices.

The behavior of the Check rooting deep scan configuration option has now been consolidated. If Check rooting deep scan is enabled in the configuration, App Shielding starts scanning the device file system for suspicious files. A file is suspicious if it has a suid or sgid attribute set or if it looks like an su binary.

Previously, the scanning for suid or sgid attributes was started even if the check was disabled, and a configured ExtendedObserver might have received a callback about suid or sgid files, but not about su binaries. Now, the scanning is only started if Check rooting deep scan is enabled. For more information, see Rooting.

To improve runtime performance, App Shielding now provides an optional Least Recently Used (LRU) cache for pull bindings. To enable an LRU pull binding cache with a maximum cache size of 3% of all pull bindings, add the following to your rules.cfg file:

~~~
cfg
bindingCache { max-size 3% }
~~~

For more information, see Least Recently Used Cache.

App Shielding version 7.0.0 introduced a new feature, Tapjacking Protection, which can be enabled with the Check tapjacking and Block tapjacking options. Tapjacking protection originally consisted of two distinct types of protection:

• Block any input to the application when a non-system overlay is detected on the screen (i.e., block tapjacking attempts).

• Block and remove non-system overlays when the protected application is running (on Android 12 and later).

Because these are two distinct types of protection, the second type, blocking non-system overlays, has been moved to its own App Shielding configuration option called Block non-system overlays. For more information, see Tapjacking.

If you were using the Check tapjacking and Block tapjacking configuration options in App Shielding 7.0.x, and you want to keep the same functionality, you must explicitly enable the new Block non-system overlays option.

The device's bootloader is responsible for loading the operating system. App Shielding can now detect if this bootloader has been "unlocked", which allows the device to then be flashed and rooted. An unlocked bootloader also suggests that the device might be running a custom and/or malicious OS.

Even though an unlocked bootloader on its own is not a security threat, it is often a first step to other potential attacks. Unlocked bootloader detection is enabled with the checkBootloaderStatus configuration option. You can also use exitOnBootloaderStatus to exit the app when an unlocked bootloader is detected, and exitOnBootloaderStatusURL to exit the app and open a browser with the configured URL to explain the problem to the user. For more information, see Unlocked bootloader detection and Exit URL Launching on Android.

This feature also adds a new ExtendedObserver callback with a BOOTLOADER_STATUS callback type and BootloaderStatusData class. Use the class's isBootloaderUnlocked() method to check the status of the bootloader. For more information, see Callbacks on Android.

On some older devices and non-GMS (Google Mobile Services) devices, it might not be possible to accurately determine the bootloader status. In these cases, App Shielding assumes the bootloader is locked to limit false positives.

This option might have a negative effect on launch performance.

You can now disable rooting checks also in the App Shielding release mode. If you disable the Check rooting configuration option, App Shielding does not run its rooting checks. Previously, the Check rooting option could only be disabled in debug mode.

By default, the Check rooting configuration option is still enabled.

The range of the recommended threshold for emulated input has been increased and lies now between 30 and 35 with a default value of 31.

Description: An issue in the guard process caused the application to terminate unexpectedly on Huawei devices.

Status: This issue has been fixed.

Description: The value of the getUntrustedScreenreaderSignature() method of the ScreenreaderData class was empty when the ExtendedObserver callback was used.

Status: This issue has been fixed.