# FaceRecognition-Android is a demo wrapped around a closed binary

> FacePlugin's Kotlin sample app for an on-device biometric engine, where the actual SDK arrives as an AAR from Google Drive because it is too large for GitHub. The demo ships with a runtime licence key bound to one applicationId, and the repository carries no open source licence.

**Faceplugin-ltd/FaceRecognition-Android** — Face Recognition, Face Liveness Detection, Face Anti-Spoofing, Face Detection, Face Landmarks, Face Compare, Face Matching, Face Pose, Face Expression, Face Attributes, Face Templates Extraction, Face Landmarks

- Repository: https://github.com/Faceplugin-ltd/FaceRecognition-Android
- Website: https://faceplugin.com/face-recognition-sdk/
- Stars: 465 · Forks: 217
- Language: Kotlin
- License: not declared
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/faceplugin-ltd-facerecognition-android

## The engine is an AAR on Google Drive

The repository is the demo app, not the SDK, and the README is explicit about the boundary.

The engine itself is `facerecognitionsdk.aar`, and it lives in a `libfacesdk/` directory. It is not in GitHub because the file is empty there, with the stated reason being that the binary is too large. You download it from a Google Drive folder linked from the README, then place it in the project next to its build file:

```text
FaceRecognition-Android/
└── libfacesdk/
    ├── build.gradle
    └── facerecognitionsdk.aar
```

The instruction not to put it in a nested folder is there because a Gradle module configured to look in one specific path will silently not find it anywhere else.

So the delivery chain is: clone the open repository, fetch a binary from a personal cloud drive folder, drop it in the right place, build. That is a normal pattern for a commercial SDK and an unusual one for something described with the vocabulary of open source.

What the repository does contain is an ordinary Android Studio project: a top-level `build.gradle`, `settings.gradle`, `gradle.properties`, the Gradle wrapper, an `app/` module, `assets/` and the `libfacesdk/` module itself.

The last push was on 2026-09-28 and there are no GitHub releases, so even the demo has no versioned artefact.

## The licence is a key, not a grant

Two different things get called a licence in this project, and only one of them is about permissions.

The SDK one is a runtime key. A `LICENSE_KEY` for the application id `com.faceplugin.facerecognitionsdk` is already committed in the repository, and the demo runs as-is with it. The rule that follows is the important one: keep that applicationId, and if you change it you have to request a new key.

That means a key is bound to the package identity rather than to a device or an account. Renaming the application to put it in your own product puts you in a different licence tier without you having changed a line of SDK code.

The other sense of licence is absent. GitHub records no licence for the repository, and no licence file appears among the top-level entries, which hold the Gradle files, the wrapper, the app module, assets and libfacesdk. There is also no tagged release.

Together those two facts define what you can do with this repository. You can read the demo, run the demo, and copy its helper code into your own app. You cannot redistribute the engine from it, and you should assume the demo source is covered by whatever terms the company's site sets rather than by an open source grant.

A help centre at a separate domain and a Docker Hub account alongside the other platforms suggest the company is the only source for the rest.

## Two ABIs, API 24, and no emulator

The system requirements table is unusually complete, and it starts by telling you what is not supported.

The AAR includes native libraries for `arm64-v8a` and `armeabi-v7a`, and the sample app filters its build to exactly those two ABIs. There is no x86 entry, which is why the emulator is called out as not recommended, and the device row says outright that an emulator is not for camera or liveness work.

The minimum column asks for Android API 24, which is version 7.0, four gigabytes of RAM, a four-core CPU, a front camera at 720p or 1080p, and a physical device. The recommended column moves to API 29 or newer, six gigabytes of RAM or more, and a mid-range system on a chip from around 2019.

Nothing there mentions a server. That is consistent with the positioning, which is a fully on-device engine for KYC and mobile onboarding where all processing stays on the device and no biometric data is sent to the vendor's cloud.

For an evaluation, the practical check is the ABI and the camera. A x86 emulator will not load the native libraries, and a physical device is required for the live identification and liveness paths to mean anything.

## The status bar gates every tile until the SDK loads

The demo has a small piece of UI that tells you more about the failure modes than the rest of the documentation does.

The home screen carries a warning bar which is the SDK status, with the text Loading native SDK while it initialises. Enroll, Identify, Capture and Attribute stay disabled until that bar disappears. So the visible symptom of a misconfigured setup is four greyed-out tiles rather than an error message.

That covers the three ways this goes wrong. The AAR in the wrong directory means the native library never loads. A missing or wrong licence key means the SDK refuses to initialise. And an unsupported ABI produces the same symptom.

Once the bar clears, four capabilities unlock, and they map to the problems the engine is sold for. Enroll takes a person from a gallery photo, exactly one face, into the on-device database. Identify is a live 1:N camera match that stops on the first hit, with 2D liveness and anti-spoofing in the loop. Capture runs an oval coach for framing, produces a still with attributes, and can optionally enrol what it captured. Attribute is gallery analysis rather than camera work, returning landmarks, liveness, pose, quality, age, gender and emotion.

Beyond the tiles the SDK also provides 14-point landmarks, template extraction, 1:N similarity and an offline licence mode.

## Settings is a threshold editor, not a preference screen

Two of the six home tiles are not demonstrations of the engine, and one of those two is the one you will spend time in.

Settings exposes the camera lens plus thresholds for identification, liveness, pose and eye closure. That is the entire configuration surface shown in the demo, and it tells you what the SDK expects to be tuned rather than merely switched on.

Liveness and pose thresholds are the ones with consequences. The identification path combines a live 1:N match with 2D liveness and anti-spoofing, so a threshold that is too permissive accepts a photograph; one that is too strict rejects a real user on a bad light. The same tension applies to eye closure. None of these values are documented with recommended defaults in the visible README, which means the settings you ship are the settings you tuned on your own test set.

Capture is the third demonstration worth understanding on its own. An oval coach guides the user into frame, and the result is a still with attributes attached, with an option to enrol it directly. That is a different entry path from Enroll, which takes an existing gallery photo, and it is the path an onboarding flow would use.

Attribute, by contrast, is the batch path: you hand it images from storage and read the analysis back.

## The kit is the part you copy into your own app

The repository's real contribution to anyone building on the SDK is not the demo screens, it is a helper package.

The demo ships copy-paste Kotlin helpers under an `app/.../kit/` directory, centred on a client class called `FaceRecognitionClient`. The stated purpose is that you can call every SDK function without rewriting the threading, the CameraX setup or the VideoWorker plumbing.

That is a specific and reasonable thing to be tired of. Camera work on Android means a camera lifecycle, a preview surface, an image analysis pipeline and a background thread for the model, and none of that has anything to do with face recognition. Writing it again for every integration is the part the kit removes.

Because it is described as copy-paste rather than as a published library, there is no version to depend on and no compatibility promise. You are copying a file into your own source tree, which means you own it immediately and you maintain it when the SDK changes underneath.

That is the trade this repository offers in one sentence: the threading is solved for you in sample code, and the engine itself is a binary you cannot inspect.

## Twelve sibling repositories, one engine underneath

The product list at the end of the README is the clearest statement of the company's shape, and it is worth reading as a map rather than a list.

Recognition is covered on Android, which is this repository, plus iOS, React Native, Flutter, Ionic Capacitor, Ionic Cordova, Windows, and Linux through Docker. That is seven platforms for the same function.

Liveness is a separate product line with four repositories of its own: Android, iOS, Windows and Docker on Linux. So the SDK this demo wraps, which includes 2D liveness and anti-spoofing in the Identify path, overlaps with a product sold separately.

The pattern across all twelve is the same. Each platform repository is a demo app plus a runtime binary fetched from outside the repository, and none of them is the engine.

The other links confirm the same pattern at the infrastructure level. There is a company site, a Hugging Face organisation, a separate help centre domain and a Docker Hub account. The Hugging Face presence is where models or assets would live rather than code.

For someone choosing a supplier, the useful signal here is consistency of packaging rather than any single implementation: the same delivery approach is applied twelve times, which is either a well-practised process or a single policy copied around.

## Conclusion

Adopt this demo app if you are evaluating an on-device face recognition engine for KYC or mobile onboarding and want to see every function called without writing the camera and threading plumbing yourself. Do not treat the repository as the product: the engine is a binary you download separately, and the licence is a runtime key rather than an open source grant. Verify two things first. Confirm your applicationId, because the included key is bound to `com.faceplugin.facerecognitionsdk` and changing it needs a new one. Then check the hardware table against your device, since the SDK ships native libraries for two ABIs only and the project says an emulator is unsuitable for camera and liveness work.

## FAQ

### Does FaceRecognition-Android include the recognition engine?

No. The engine is the file libfacesdk/facerecognitionsdk.aar, which is empty in the repository because the binary is too large. You download it from a Google Drive folder linked in the README and place it next to libfacesdk/build.gradle.

### What licence is FaceRecognition-Android under?

GitHub records no licence for the repository and no licence file appears in its top-level entries. What the project does ship is a runtime LICENSE_KEY already set for the application id com.faceplugin.facerecognitionsdk. Changing the applicationId means requesting a new key.

### What devices can run the FacePlugin Android SDK?

The AAR ships native libraries for arm64-v8a and armeabi-v7a only, so a physical device is needed rather than an x86 emulator. The minimum is Android API 24 with 4 GB of RAM, four CPU cores and a front camera at 720p or 1080p, and the recommended setup is API 29 or newer with 6 GB or more.

### How do I know the FacePlugin SDK actually loaded?

A warning bar on the home screen shows the SDK status, with the text Loading native SDK while it initialises. The Enroll, Identify, Capture and Attribute tiles stay disabled until that bar disappears, so a missing AAR, a bad licence key or an unsupported ABI all look the same: four greyed-out tiles.

### What can I reuse from the FaceRecognition-Android demo?

The helper package under app/.../kit/, built around a FaceRecognitionClient class, is written to be copied. It exists so you can call the SDK functions without rewriting the threading, CameraX or VideoWorker plumbing. It is sample code rather than a published dependency.

## Sources

- [Faceplugin-ltd/FaceRecognition-Android on GitHub](https://github.com/Faceplugin-ltd/FaceRecognition-Android)
- [Issues](https://github.com/Faceplugin-ltd/FaceRecognition-Android/issues)
- [Project website](https://faceplugin.com/face-recognition-sdk/)
- [README](https://github.com/Faceplugin-ltd/FaceRecognition-Android/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/faceplugin-ltd-facerecognition-android