HUMAN supports Android SDK version 22 (5.1 Lollipop) and higher.
From v1.15.3, HUMAN requires Kotlin 1.4.0 or higher.
The HUMAN Android SDK works by constantly profiling and evaluating device behavior to ensure the connections to your mobile APIs and services are genuine.
This process requires initializing a context to manage a set of secure HTTP headers. The headers are added to all HTTP and HTTPS requests made by the mobile application to the origin server. The HTTP headers are refreshed on a regular basis by the HUMAN Manager (context) as it profiles the end-user’s mobile device.
The following are required to install the HUMAN Android SDK:
(the official repository for hosting the HUMAN Android SDK).
The repository can be integrated with Maven, Gradle, or Ivy.
<version_to_download> should be replaced with the correct version.
In Maven, run:
In Gradle, run:
In Ivy, run:
To import and integrate the Android SDK in an Android application edit the project’s build.gradle file and add the following maven and mavenCentral configurations:
The SDK is now installed, and there should not be any build errors when compiling your application.
In your AndroidManifest.xml add:
XML example:
Import the following classes into your Application class or the main activity:
In your onCreatemethod initialize the HUMAN Manager (using your HUMANApp ID):
In your project, add a new class called PXBridge and set it to extend ReactContextBaseJavaModule:
Add the class constructor:
Add the following methods:
The bridge exposes the minimal methods required for the SDK to operate:
getHttpHeaders - returns a JSON file containing the HUMAN HTTP headers.verifyResponse - verifies the 403 response and based on its content - either returns the response unchanged or calls the SDK’s handleBlockResponse method.Add a new class called PXBridgePackage and set it to extend ReactPackage:
Add the following methods to the new class:
In your app’s MainApplication.java, add the PXBridgePackage class to the end of the array returned by the GetPackages()method:
Once the HUMAN Manager is initialized, you need to add the HUMAN HTTP Headers to every network request your app is making. These headers can be retrieved by calling the PXManager.httpHeaders() method of the SDK, which is exposed to the JavaScript side by the bridge created in the previous step.
Using Axios
To add the HUMAN HTTP headers to every request using Axios, use the following example:
Using Fetch
To add the HUMAN HTTP headers to a fetch request, either add the headers directly to each request or create a wrapper like the following example:
When a HTTP request is denied by HUMAN, a 403 response code is sent in the HTTP response along with a JSON body encoded as a UTF-8. The encoded JSON body is parsed and used by the HUMAN Android SDK. The parsed JSON is then used to render a WebView to either challenge (with CAPTCHA) the visitor or block the visitor from continuing in the application. If the user solves the presented challenge they will return to the application. If the user fails the CAPTCHA challenge they continue to be challenged until they pass the verification screen.
Using Axios
The easiest way to implement the error handler is with Axios’s response interceptor:
Using Fetch
You can also implement the error handler using a Fetch based wrapper:
When the application request is blocked by the HUMAN Enforcer, the SDK takes control and a Captcha page is displayed. Attackers may attempt to use Android’s back button to return to the previous screen and continue malicious behavior. HUMAN allows you to enable or disable Android’s back button functionality. When the back button is enabled, touching the back button returns the attacker to the previous screen. Any additional network calls cause the SDK to block the attacker again. By disabling the back button, the attacker remains on the CAPTCHA page until he solves the Captcha challenge, or until he exits the application and relaunches it. When the application is relaunched, any additional network call is blocked with a Captcha page.
By default, the SDK enables using the back button.
To disable the back button, add the following code to the HUMANManager object during initialization of the SDK:
Inside the onBackButtonPressed method you can add the code of your choice to return the blocked user to his previous flow.
Custom parameters allow you to collect and send specific app or device information to be used later for aggregations and intelligence.
Using the PXManager*setCustomParameters()` method you can specify up to 10 custom parameters to be sent to HUMAN servers on every network request.
setCustomParameters() accepts a Map of type [String, String] with all the keys beginning with custom_param followed by a number (1-10).
The setCustomParameters() method is set once before calling the start method.
The following example adds 2 custom parameters:
Added in version: v1.15.2
If your application includes a WebView, you need to allow HUMAN SDK to handle the session connection between the web view and the application.
To do that, after you create a web view instance (or get its reference from the view), call:
The Account Defender Manager instance is retrieved by calling PXAccountDefenderManager.getInstance(context) with a context object. To enable the feature, a user ID must be set. That can be done by calling the PXAccountDefenderManager.setUserID function and providing the user ID. When the user ID is changed, the function should be called again with the updated user ID. If the user logs out, the function should be called with nil. The function should be called after the PXManager.startWith function.
To register outgoing URL requests, call the PXAccountDefenderManager.registerOutgoingUrlRequest function with the URL. This function should be called only when Account Defender is enabled (user ID is set).
HUMAN uses the application’s user agent to identify and differentiate between application versions. For accurate detection it is important that the user agent your application reports is informative. Here is the recommended convention:
The “Doctor App” is a tool to help you verify the mobile SDK integration by simulating a typical user flow in your application. To enable this feature, add the enableDoctorCheck = true parameter in the start method.
This feature is for development purposes only and should not be shipped with your application to the application store.
Example:
Flow:


When you exit the doctor app, your application will also terminate. Just remember to switch the ‘enableDoctorCheck’ parameter to false when you finish validating your integration with HUMAN mobile SDK.
To verify that SDK is implemented correctly, print a line to the console when the ManagerReady callback is fired.
A log line similar to the example below should be displayed in your Android Monitor window:
Connect to the device with ADB and run adb logcat | grep InternalManager.
This should produce the following output indicating the SDK has started and is in a ready state:
Connections to your API endpoint can be inspected using a local proxy such as CharlesProxy_.
When inspecting requests look for the HTTP header named X-HUMAN-AUTHORIZATION.
Requests to the perimeterx.net domain are also pinned to a specific SSL certificate and cannot be inspected with Charles Proxy. If you have enabled SSL proxy for all domains you must exclude perimeterx.net.
If this header is not present go back to the application code responsible for making the request and review to verify the headers were added to the request properly.
Denied requests have one of two possible actions, block or challenge, and both should be validated to ensure the request is properly handled.
Developers integrating with the HUMAN Mobile SDK can be given access to the HUMAN Portal in a developer role. They then have access to the Developer section, which contains the Mobile Enforcement Verification tool. This tool allows a developer to mark their requests to be denied for testing purposes.
The testing tool is necessary to validate denied requests.
Make sure the enforcer you are testing against is set to blocking mode before proceeding with the instructions.
To validate a challenge response:
To validate a blocking response:
To configure your Android Emulator:
In certain cases, the HUMAN Mobile Sensor (SDK) may need to be deactivated remotely, and the app run without any sensor intervention.
This can be done based on any combination of the following parameters:
To deactivate the HUMAN Mobile Sensor, contact your assigned focal point within HUMAN. Portal support to allow deactivation via the Portal will be added in the future.
The default cutout mode is set to Never, meaning the challenge page will not render on the cutout area:
To change the behavior to SHORT_EDGES, and have the page render on the entire display area, set the setIsCutoutFullScreen() to true.
The setIsCutoutFullScreen() method is set once before calling the start method.
Full screen on devices with display cutouts is supported on Android version P (API level 28) and above and HUMAN SDK version 1.7.0 and above.
The challenge page will now render over the entire display