How to Implement Threat Event Handling in Android SDKs
Overview
Security is a paramount concern in the development of Android SDKs, especially when these SDKs are integrated into various applications. This article provides a detailed guide on how to implement threat event handling within an Android SDK (.aar file). It explores the necessary modifications to the AndroidManifest.xml to configure permissions and event listeners and demonstrates how to handle specific threat events such as “AppIntegrityError,” “AppIsDebuggable,” and more.
Understanding Threat Events for SDKs
Threat events in the context of SDK Protect are specific security alerts related directly to the SDK’s operational integrity and security. For instance, Appdome uses notification methods to pass these events from its layer back to the SDK. As a result, the SDK can take appropriate actions in response to malicious activities detected by Appdome, improving its capability to protect itself without directly involving the host application.
Step 1: Configure AndroidManifest.xml
To set up your SDK for threat event handling, start with the AndroidManifest.xml. This configuration file needs to declare the necessary permissions that will listen for these threat events.
<?xml version="1.0" encoding="utf-8"?>
<manifest
xmlns:android="http://schemas.android.com/apk/res/android">
<uses-permission android:name="android.permission.INTERNET" />
<application>
<meta-data android:name="ThreatEventReceiver" android:value="
<app_bundle_id>.<Appdome_SdkEventListener_Example>" />
<meta-data android:name="ThreatEventNames" android:value="AppIntegrityError,AppIsDebuggable" />
</application>
</manifest>;
Replace <app_bundle_id>.<Appdome_SdkEventListener_Example> with the actual package and class name of your event listener.
Step 2: Implement the SdkEventListener
Create or modify the class within your SDK that will handle the threat events. This class should conform to the expected interface provided by your SDK.
The following code provides the implementation for the <Appdome_SdkEventListener_Example>
Class, which will handle threat events.
Note: Replace all class name instances labeled <Appdome_SdkEventListener_Example>
with the specific name of your class listener name. This is crucial to ensure your code functions correctly with the intended event data. In addition, make sure that your class includes the function “public void onReceive(Context context, Intent intent)” signature.
Java
public class <Appdome_SdkEventListener_Example> {
public void onReceive(Context context, Intent intent) {
Log.i("tag: <Appdome_SdkEventListener_Example>", "msg: received event intent: " + intent.toString());
Log.i("tag: <Appdome_SdkEventListener_Example>", "msg: found event of type: " + intent.getAction());
if (intent.getAction() == "AppIntegrityError") {
Log.i("tag: <Appdome_SdkEventListener_Example>", "msg: AppIntegrityError event handling");
} else if (intent.getAction() == "AppIsDebuggable") {
Log.i("tag: S",
"msg: AppIsDebuggable event handling");
}
}
}
Meta-Data for Mobile SDK Threat Events
Below is the list of metadata that can be associated with each mobile SDK built with a .aar
Context Key | Reason |
reasonCode |
Reason code of the occurred event |
fusedAppToken |
The task ID of the Appdome fusion of the currently running SDK. |
kernelInfo |
Info about the kernel: system name, node name, release, version, and machine. |
reasonData |
Reason for the attack. For example, root detection. |
defaultMessage |
A pre-defined message that will be displayed to the SDK or logged when a specific event occurs. |
message |
A message will be displayed to the SDK when an event occurs. |
timestamp |
The exact date and time when the event occurred are recorded in a standard timestamp format. |
By configuring the SDK in this manner, you facilitate Appdome’s listening to the defined threat events. When such events are detected, Appdome can trigger threat event notifications to the SDK, allowing for immediate and automated handling of these threats. This integration not only enhances the SDK’s security features but also automates the response process, reducing the manual overhead in monitoring and responding to security issues.
This setup empowers SDK developers to leverage advanced security automation tools provided by Appdome, enhancing the SDK’s ability to protect itself and the applications it serves from emerging security threats.
Related Articles:
- How to Obfuscate SDK Logic using Appdome SDKProtect™
- How to Use Appdome SDKProtect to Secure Mobile SDKs
- Automated SDK Protection – Appdome SDKProtect™
How Do I Learn More?
If you have any questions, please send them our way at support.appdome.com or via the chat window on the Appdome platform.
Thank you!
Thanks for visiting Appdome! Our mission is to secure every app on the planet by making mobile app security easy. We hope we’re living up to the mission with your project.