-
Notifications
You must be signed in to change notification settings - Fork 5
Frequently Asked Questions
This new error is not for general use cases but only for iProov internal use. Integrators will never see it on their SPs.
Please look at this page about updating for use past Dec 2024
The normal IProovState responses of Connecting, Connected, Progress, etc will not help here.
And end-integrator can of course simply hook into their own Activity lifecycle to know when the iProov Activity has started and stopped.
For library developers, this option is not available.
For just this use-case, we have a solution: create a class that implements ActivityLifecycleCallbacks and use (context.applicationContext as Application).registerActivityLifecycleCallbacks(this), and its related unregister variant, to hook into the lifecycle events of any current Activity. You would be looking for any of these four iProov Activities: FullPortraitActivity, FullLandscapeActivity, FullReversePortraitActivity, FullReverseLandscapeActivity. You might also like to realise that once the iProov Activity enters the lifecyle state of Pause, it will NOT return. This is because any attempt by the user to switch apps (causing the pause) is considered a user-cancelation by iProov.
The problem reported in this CVE (https://nvd.nist.gov/vuln/detail/CVE-2023-3635) is fixed on version 3.4.0 of the okio library here.
You can upgrade the library to version 3.4.0 by adding the following to your build.gradle file
implementation 'com.squareup.okio:okio:3.4.0'
Be aware that this version of the okio library requires your app to be using kotlin version 1.8.0.
From Android 10, Dark Mode introduced a way to change the system colours on the fly. Normally, iProov does not need to consider configuration changes since it does not allow rotation during a scan. It was possible, albeit unlikely, that someone could start a scan then change dark/light mode causing a crash. This has been fixed in the following places:
- 7.5.2 - this hot fix, which requires a special repository maven path:
maven { url "https://raw.githubusercontent.com/iProov/android/patch752/maven/" } - 8.4.1 (and all subsequent versions)
To avoid the activity to re-create in your own apps, just include android:configChanges="uiMode" for the Activity in the Manifest.xml.
As of Android 11, apps will find their runtime permissions expiring, requiring the user to allow them again. This is not a problem because iProov checks for permissions on every scan and follows the correct procedure to request access.
IProov Android SDK depends indirectly on okhttp 3.8.1. All reported implementation issues related to okhttp at the time of writing this note, have been due to the use of okhttp 4.x. Therefore, using okhttp 3.x is generally the solution.
This can be achieved by downgrading the dependency that provides 4.x, by excluding okhttp package from that dependency or by a combination of both of these.
Please note that a 3.x version is not necessarily older than 4.x one.
We also recommend that you check the actual dependency tree, as gradle can potentially resolve dependencies differently to what you might assume.
If you still have issues while using okhttp 3.x:
You might encounter a bug in Android 11 with error "Expected Android API level 21+ but was 29". It seems that okhttp versions lower than 3.13.0 are not affected by this bug, so if you find this error then you have a dependency that is probably forcing an affected version of okhttp. If that's the case you should use okhttp 3.14.7, as the bug was fixed in that version, or later.
Generally you should not find any issue if this is the case. If still you have an issue in this scenario, then it is likely that you have a dependency that is forcing a version of okhttp higher than 3.12.12. Nevertheless, if that's the case you will have minSDK 21 instead and your app would crash in API 19. Everything should work as expected once you fix it to be a truly minSDK 19 app.
v6.3.0 has an updated direct dependency and that brings our indirect dependency of okhttp3 up to 3.12.12 by default.
We know that SDK size impact is an important factor, and we continue to do everything we can to pack iProov's advanced technologies into as small a payload as possible. We get asked this question quite a bit, and it's a hard one to answer.
In addition, app downloads from Google Play are compressed, which further reduces the SDK size impact.
Since the size impact of the iProov SDK depends heavily upon the configuration of your existing app, it is impossible to provide an accurate determination of size impact across all possible scenarios.
However, to provide a rough estimate, we followed the following procedure:
A. Produce a basic app and generate an APK.
B. Modify the same app to with the iProov SDK included, and generate an new APK
Installing each time onto the same device and reading the "app info" we can determine the size impacts.
The following are approximate increases in app sizes when selecting each face detector and including only their required aar library dependencies. This test was done on v8.3.1 and v8.1.1.
| Face detector | AARs added | App size increase |
|---|---|---|
| Classic | iproov | 1.3MB |
For the latest tests we start with a vanilla app and add the dependencies of the SDK and then the SDK:
| New App | New App + SDK Deps | New App + SDK |
|---|---|---|
| 1.0 MB | 1.5 MB | 3.7 MB (10.2.0) 4.0 MB (10.2.0-pf) |
Therefore we conclude that the dependencies of the SDK add 0.5 MB.
Since an app that uses the SDK could already have anything from zero to all dependencies in common with the SDK then the ultimate release build size of including the SDK varies as follows:
| Protobuf Variant | Min | Max |
|---|---|---|
| 10.2.0 (lite) | 2.2 MB | 2.7 MB |
| 10.2.0-pf (full) | 2.5 MB | 3.0 MB |
On some very low-end devices, the system performance is insufficient to provide a smooth iProov experience. We are always looking at optimizing the Android SDK experience on low-end devices.
You should also ensure you are not running the SDK with the Android Studio debugger attached as this has a significant performance impact. You should also check the Known Issues page
iProov Android SDK 6.0+ uses AndroidX, therefore you must use AndroidX.
If you are still using Android Support Libraries, you must continue to use iProov Android SDK 5.x (no longer supported). We would encourage you to move to AndroidX as soon as possible.
This option was introduced in SDK v5.2.3, and removed in 8.0.0.
Sometimes this error is erroneously triggered in pre 8.x versions for other reasons that are fixed in 8.x+.
For most cases, leave this value as null (default).
In some cases, you might want the iProov Activity to be started using startActivityForResult() instead of startActivity(). Typically, this is because your Activity has launchMode="singleInstance" set in the manifest, due to a strange side-effect of how singleInstance Activities are handled in Android. Note: This is strongly discouraged by both Google and iProov!
If you must use singleInstance for whatever reason, then ensure that you pass your calling Activity as the context to IProov.launch() and set a value for options.ui.activityCompatibilityRequestCode, which will be the requestCode for the result. This allows you to identify (and ignore) the result from iProov (which is always zero) in onActivityResult() if you have already implemented it.
If you are using Play Feature Delivery in your app and iProov is part of one of your dynamic features, you need to consider the following.
When building your app, the iProov SDK's AndroidManifest.xml is merged with your module's AndroidManifest.xml file. Then, the manifest file of each module is merged into the app's module. At this point in the process, while the manifests are being merged, the resources from the style.xml files of the iProov SDK are not available to the app's module, which causes the following error:
Android resource linking failed
<path_to_your_app>/app/build/intermediates/packaged_manifests/debug/AndroidManifest.xml
error: resource style/iproov__AppTheme (aka <package_name>:style/iproov__AppTheme) not found.
To avoid this problem, include the following style in your app's module themes.xml file so the resource is available for this module when manifests are merged.
<style name="iproov__AppTheme" />