Release Notes Mobile Application Shielding for Android Version 8.0.1 (July 2025)

With the new Memory Scan detector, App Shielding checks for unauthorized memory access or scanning activity. If a malicious memory scan is detected, the application is terminated. Memory Scan is enabled by default and can be disabled with the new Check Memory Scan configuration option.

Description: When an ExtendedObserver instance was removed while handleCallback was active, a deadlock occurred.

Status: The provided example code no longer causes a deadlock:

```kotlin
    package com.example

    import no.promon.shield.callbacks.CallbackData
    import no.promon.shield.callbacks.CallbackManager
    import no.promon.shield.callbacks.ExtendedObserver

    class ExampleObserver() : ExtendedObserver {
        override fun handleCallback(data: CallbackData?) {
            [...]
            CallbackManager.removeObserver(this)
        }
    }
  ```

Description: After successfully shielding a large application, App Shielding displayed a NoSuchKey error when the user tried to download the shielded application.

Status: This issue has been fixed. During the shielding process, App Shielding displays the log file with the shielding progress, and once shielding has completed, the user can download the app.

The rooting detection has been improved when the shielded app has the QUERY_ALL_PACKAGES permission set for root hider tools.

Description: Screenshots were incorrectly blocked even after an updatable configuration disabled the Block screenshots configuration option.

Status: This issue has been fixed.

This version of App Shielding also resolves several stability issues and improves overall compatibility:

• improved performance consistency by adjusting the internal toolchain

• resolved rare unexpected termination that occurred in a race condition when activities where switched rapidly

• addressed rare unexpected termination caused by memory access

Initial detection has been added for APatch rooting when a module is enabled.

The internal app parsing tool was replaced with the official Google version, adding support for Dex version 40.

Description: If the Shielding Tool was used to remove unsupported native libraries from a feature module in an app-bundle, bundletool build-apks (or bundletool validate) failed to handle the input app bundle.

Status: This issue has been fixed.

Description: An aggressive bootlader state heuristic triggered false positives for rooting and unlocked bootloader detection.

Status: This issue has been fixed.

Description: On GrapheneOS, a self-signed boot state triggered false rooting positives.

Status: This issue has been fixed.

Description: An issue occurred with unblocking a trusted  screen reader (e.g. TalkBack) when blockUntrustedScreenreaders was set, and the screen reader was enabled while the protected app was running.

Status: This issue has been fixed.

Description:The methods used to block screenshots also block some screen mirroring tools. However, the scrcpy tool is only blocked on Android 12 and later. On Android 15, this option also blocks partial screen sharing.

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.

Description: When using the shielded version of the app, NFC payments fail. This is caused by a compatibility issue with the Thales Gemalto TSH Pay SDK which also provides debugger detection. The SDK incorrectly flags the App Shielding debugger detection as a native debugger.

Solution: Allowlisting. For implementations integrating both the Thales Gemalto SDK and App Shielding, debuggers coming from the SDK's own debugging processes and sub-processes should be added to an allowlist within theThales Gemalto SDK.

It is essential to not only add the processes to the allowlist but also their sub-processes. Otherwise, the SDK will still handle App Shielding as a native debugger!

Root hider tools such as Magisk Hide are designed to hide the fact that the device is compromised (rooted). Android has been increasingly restricted in what can be inspected and observed of the system from inside an app. This means that a rooted system with a root hider tool can be hard to detect due to missing privileges.

On Android 8+, App Shielding may not able to reliably detect a rooted device with Magisk Hide depending on the version of these tools.