Skip to main content

SDK Setup

Let's walk through the SDK setup.

Maven Repository​

Please refer to the Repository Setup.

Android SDK Version Settings​

First check the version settings of your project.
These are the recommended settings:

android {
    namespace 'com.example'
    compileSdk 35

    defaultConfig {
        applicationId 'com.example'
        minSdk 30
        targetSdk 35
    }
}
Further details

We recommend to keep the minSdk version at the displayed value above.
It is however possible to decrease minSdk version to as low as 27 (Android 8.1).
The compileSdk version can not be lower then the displayed value above.
We are obligated by our certifiers to keep our third party dependencies up to date.
These dependencies often require the most current version of the Android SDK.
Lowering our third party dependency versions would result in our certification being voided.

caution

The compileSdk version might increase with new versions of the SDK as it is subject to PCI requirements

ABI Filters​

The PhonePOS SDK currently supports the arm64-v8a ABI (Application Binary Interface), which does cover the overwhelming majority of devices in the market. The following ABIs are NOT supported by PhonePOS:

  • armeabi-v7a (32-bit ARM, in outdated phones)
  • x86 (in e.g. Chromebooks, older Intel phones, emulators, ...)
  • x86-64 (in e.g. Chromebooks, older Intel phones, emulators, ...)

The integration of the PhonePOS SDK on a device with an unsupported ABI will lead to an app crash. To prevent crashes please integrate the so called abiFilters variable into your main app gradle.build file:

android {
    defaultConfig {
        ndk {
            abiFilters 'arm64-v8a'
        }
    }
}
caution

In 2023, Google changed their testing approach for new app releases. They now also utilize x86 devices in their device pool. If the abiFilters are not set correctly you might encounter errors when your app is uploaded to the Google Play Console.

Packaging Options​

We include multiple dependencies into our SDK. Conflicts arise from native packages having the same package name or packages containing a dependency list. Please include the following:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
            pickFirst 'lib/arm64-v8a/libc++_shared.so'
        }
        resources {
            exclude 'META-INF/**'
        }
    }
}

To enable overriding the android:label and android:supportsRtl with your own calues, add the following tools:replace value in your AndroidManifest.xml file.

<manifest>
    <application 
        tools:replace="android:label,android:supportsRtl">
    </application>
</manifest>
caution

For security reasons, please refrain from overriding the defaults for android:allowBackup, android:dataExtractionRules and android:fullBackupContent with your own values.
These values are usually set for new projects, please remove them.

SDK Dependency​

When the repositories are all setup, we can include the SDK binary.
We will supply you with the right flavor and version.

android {
    compileOptions {
        // needed since PhonePOS version 3.14.02.18
        coreLibraryDesugaringEnabled true
    }
}

dependencies {
    coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs_nio:2.1.5'
    implementation 'com.rubean.phonepos:sdk:{VERSION}'
}
tip

For the integration phase you will receive a QA flavor which points to our QA environment. When you have finished integrating the PhonePOS SDK and also sent us your public signing key we will provide you with a production version that integrates more strict protections.
Example:

  • QA: com.rubean.phonepos:sdk-qa:{VERSION}
  • PROD: com.rubean.phonepos:sdk:{VERSION}

SDK API Key​

info

This only applies to versions starting from 4.XX.XX.XX

Our SDK identifies the correct environment via an API Key and API Secret. We will provide you with this information. While it is possible to pass the API Key and Secret during personalization as a parameter it is highly preferable to set it in yourAndroidManifest.xml:

<manifest>
    <application>
        <meta-data
            android:name="API_KEY"
            android:value="..." />
        <meta-data
            android:name="API_SECRET"
            android:value="..." />
    </application>
</manifest>
warning

If the API_KEY and API_SECRET are not defined in your AndroidManifest or in the personalisation call, all personalisation attempts will fail.

AppAnchor​

A submodule of our SDK requires a so-called AppAnchor, which is essentially a class that extends the Application and hooks into the Android Application Lifecycle.

tip

By default you are NOT required to do anything here. This is only required in the following case:

If you to extend the default Application in your project by yourself for any given reason, you need to make sure that the AppAnchor is still correctly initialized. To achieve this, you can extend your own Application class from the AppAnchor instead of Application:

public class MyApplication extends AppAnchor { 
    @Override
    public void onCreate() {
        super.onCreate();
        /// ...
    }
    
    @Override
    public void onTerminate() {
        super.onTerminate();
        /// ...
    }
}

In the AndroidManifest.xml, as usual, you then override the android:name with your own Application class

<manifest>
    <application
        android:name=".MyApplication"
        tools:replace="android:name">
    </application>
</manifest>