Troubleshooting

View product v1.1.1

Malwarelytics for Android is an Android SDK that is packed as a .aar package and it is distributed as a Gradle dependency. Android applications vary greatly and some might experience various types of issues with the SDK. Here are listed some common approaches to solving frequent problems.

SDK Fails to Initialize

The SDK can be initialized asynchronously or synchronously. In both cases, it returns an InitializationResult value indicating online/offline mode or potential problem. In case the SDK fails to initialize (onInitialized(InitializationResult) callback not called) there might be an issue with the build. Possibly another library or framework affects the SDK.

Wrong API Credentials

When incorrect API credentials are passed to the SDK configuration, the initialization returns with InitializationResult. PERMANENT_OFFLINE_MODE. The value indicates that the SDK is not able to communicate with the remote server and the communication cannot be reestablished without a change to the configuration. The configuration items responsible for API credentials are the following:

val config = AppProtectionConfig.Builder(appContext)
    .apiUsername(API_USERNAME)
    .apiPassword(API_PASSWORD)
    .apiSignaturePublicKey(API_SIGNATURE_PUBLIC_KEY)
    // other configuration items
    .build()

The API_USERNAME, API_PASSWORD, and API_SIGNATURE_PUBLIC_KEY can be found in the Malwarelytics console.

The values of API credentials have to correspond with the application’s package name as defined in the Malwarelytics console.

JaCoCo

JaCoCo Java Code Coverage Library is sometimes used in apps’ debug builds. This library changes the code of the app and all included libraries/SDKs. Unfortunately, it also affects the normal function of Malwarelytics for Android. It can cause the SDK to fail to initialize or other unexpected behavior (e.g. callbacks not being triggered).

Malwarelytics for Android is not compatible with the usage of JaCoCo.

We recommend disabling test coverage for build variants utilizing Malwarelytics for Android.

Some Application Are Not Detected

There are cases in which Malwarelytics for Android cannot detect certain applications. Android supports multiple users on a single Android device. Malwarelytics for Android can see only apps installed within the same user as the app containing the SDK. Also, apps can be installed in special separated and protected app spaces such as Android work profile or Samsung’s Secure Folder. Malwarelytics for Android isn’t able to see apps installed in these spaces unless the app containing the SDK is also installed in the same space.

Malware Seems to be Wrongly Evaluated

In some cases, the malware evaluation can generate false positives or false negatives. The most frequent cause for this issue is missing data from the server. Sometimes updates fail for various reasons, the SDK offers some info data about the last successful and unsuccessful updates in the UpdateInfo data class. To obtain the info call:

val antivirus = AppProtection.getInstance().getAntivirus
val updateInfo = antivirus.getUpdateManager.getLastUpdateInfo()

The contents of the update info are described in the Smart Protection section in greater detail.

Sensitive Permissions

Malwarelytics uses sensitive android.permission.QUERY_ALL_PACKAGES permission. Thanks to the permission the SDK can see all the apps installed on the device (within the same user and the same protected space).

Several features of the SDK use this permission, namely malware threat identification, tapjacking protection, app presence detection, root detection.

The permission android.permission.QUERY_ALL_PACKAGES is sensitive and requires Google Play Prominent Disclosure. Therefore some apps would rather not include it. Android build system allows that.

No `QUERY_ALL_PACKAGES` permission

When removed, the QUERY_ALL_PACKAGES permission affects all the features that use it. Some features become unusable while others are only slightly affected. Most of the RASP features are not affected by the missing permission.

Anti-Malware

The most important consequence of the missing permission is that the whole Anti-Malware feature becomes unusable, it will not be able to see the apps installed. In this case, we recommend completely turning off the feature.

val config = AppProtectionConfig.Builder(appContext)
    .antivirusConfig(
        AntivirusConfig.Builder()
            .enableAntivirus(false)
            .build()
    )
    // other configuration items
    .build()

Tapjacking Protection

Tapjacking protection heavily uses the Anti-Malware feature as a source of data for its function. Without the permission and working Anti-Malware feature, tapjacking protection cannot distinguish which apps are problematic and all apps capable of creating overlays are marked as “problematic”. In this case, it’s recommended not to use tapjacking protection because of a significant risk of false positives.

Tapjacking protection can be disabled in the configuration with:

val raspConfig = RaspConfig.Builder()
    .tapjacking(
        TapjackingBlockConfig.Builder()
            .action(BlockConfig.NoAction)
            .build()
    )
    // configuration of other RASP features
    .build()

App Presence Detection

App presence detection uses the permission for detecting unwanted apps. The feature detects only certain apps that were defined in the feature configuration. In case the list of apps is known in compile time, the app can use package queries instead of the QUERY_ALL_PACKAGES permission. In this case, it’s necessary to add a package query for every app added in AppPresenceDetectionConfig.

<queries>
    <package android:name="com.example.unwantedapp1" />
    <package android:name="com.example.unwantedapp2" />
    <!-- package names (android IDs) of other unwanted apps -->
</queries>

Root Detection

The whole root detection feature uses a large list of various detections. Removal of the QUERY_ALL_PACKAGES would affect a small portion of the detections, but the whole feature would remain working. As a result, the sensitivity of the root detection would be slightly worse.

KeyStore Operation Exception

Some Pixel devices on Android 14 cannot properly handle concurrent access to the Android KeyStore API and some other Android APIs. If a “mysterious” exception related to keystore operation starts appearing on some Pixel devices with Android 14, this exception might be related to device fingerprinting. In this case, we recommend changing your device fingerprinting configuration to FingerprintType.SAFE.

Read more about Problematic Devices for Fingerprinting.