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="RootedDevice,SslInvalidCertificateChain" /> </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.
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: RootedDevice event handling"); } else if (intent.getAction() == "RootedDevice") { Log.i("tag: S", "msg: RuntimeBundleValidationViolation 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.
Important Note: Proper Handling of UI Components
When integrating threat events into your Android SDK, it’s important to handle UI operations correctly to avoid errors. This is especially crucial when using functions like Toast that create popup messages.
Sometimes, when you try to show a popup message (like a toast) directly from a background operation, it can cause the app to crash with an error. This is because popup messages need to be shown from the main thread of the app that handles user interactions.
Example Error Message:
10-22 15:15:32.291 10782 10838 E [CORE ] : [TID: 10838] [:137] crashOnException() Exception occurred: 10-22 15:15:32.292 10782 10838 F appdome.aartes: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: JNI IsSameObject called with pending exception java.lang.RuntimeException: Can't toast on a thread that has not called Looper.prepare()
To address this issue, you should use a common code pattern that ensures these messages are displayed correctly:
public class SdkEventListener { public void onReceive(Context context, Intent intent) { if (context == null) { Log.e("SdkEventListener", "context is null"); return; } Handler mainHandler = new Handler(context.getMainLooper()); Runnable myRunnable = new Runnable() { @Override public void run() { Toast.makeText(context, "THIS IS A TEST TE: " + intent.getAction(), Toast.LENGTH_SHORT).show(); } }; mainHandler.post(myRunnable); Log.i("SdkEventListener", "received dev event intent: " + intent.toString()); Log.i("SdkEventListener", "found event of type: " + intent.getAction()); } }
This approach ensures that the SDK can safely interact with the user interface without causing errors. It’s a common technique for managing UI operations in Android when dealing with background tasks.
Related Articles:
- How to Obfuscate SDK Logic using Appdome SDKProtect™
- How to Use Appdome SDKProtect to Secure Mobile SDKs
- Automated SDK Protection – Appdome SDKProtect™
- Resolving the “Can’t Create Handler Inside Thread That Has Not Called Looper.prepare()” Exception in Android
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.