FacePlugin Face Recognition SDK for Android: a fully on-device demo app with a closed AAR

What FacePlugin's Android repository actually contains

The repository is not the recognition engine. The README describes it as the Android demo app, a standalone customer repo whose runtime is libfacesdk/facerecognitionsdk.aar. That file is empty on GitHub because the binary is too large, so the working code arrives from a Google Drive folder linked in the README. Kotlin is the language of the demo layer, and the repository layout matches that split: app/ holds the demo activities, assets/ and gradle/ hold supporting files, and libfacesdk/ holds the build script plus a placeholder for the AAR.

The audience is narrow and specific. The README frames the SDK as an on-device biometric engine for KYC and mobile onboarding, listing banking, access control and privacy-first identity apps. If your requirement is that no biometric data leaves the device, that is the design claim being made: all processing stays on the device and no biometric data is sent to FacePlugin cloud. The demo exposes six tiles, Enroll, Identify, Capture, Attribute, Settings and About, which map closely to the SDK surface: gallery enrollment, live 1:N matching, coached capture, and attribute reading that includes liveness, quality, pose, age, gender and emotion.

How the demo, the AAR and the license fit together

Three layers are visible in the repository. The top layer is the demo app you open in Android Studio. The middle layer is app/.../kit/, which the README describes as copy-paste Kotlin helpers around a class named FaceRecognitionClient, intended to spare you from rewriting threading, CameraX and VideoWorker plumbing. The bottom layer is the AAR, which contains the native libraries and the recognition logic.

The data flow the README describes is local. A face is enrolled from a gallery photo containing exactly one face and stored in an on-device database. Identification then runs against the live camera in 1:N mode and stops on the first hit, with 2D liveness or anti-spoofing applied. Capture uses an oval coach to produce a still image with attributes, which can optionally be enrolled. The SDK also exposes 14-point landmarks, template extraction and 1:N similarity scoring.

Licensing is offline and bound to the package name. The demo ships with a valid LICENSE_KEY for com.faceplugin.facerecognitionsdk, and the README says to request a new key only if you change applicationId. That is a real constraint rather than a formality: renaming the package is the first thing many teams do, and it invalidates the bundled key. The README does not document what happens at runtime when a key is invalid, so the failure mode is unconfirmed.

Installing the AAR and running your first enrollment

The README gives a quick start checklist that begins with cloning the repository. The clone command is explicit and puts you at the repository root.

git clone https://github.com/Faceplugin-ltd/FaceRecognition-Android.git
cd FaceRecognition-Android

After cloning, download facerecognitionsdk.aar from the Google Drive folder linked in the README under Get the AAR. The placement is strict: the file goes directly into libfacesdk/, next to libfacesdk/build.gradle, not into a nested folder. The README shows the expected tree.

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

With the AAR in place, open the folder in Android Studio and run on a physical phone. The README states that the demo already carries a valid LICENSE_KEY for com.faceplugin.facerecognitionsdk, so no key work is needed for the sample. On launch, the home screen shows a status bar reading Loading native SDK. Enroll, Identify, Capture and Attribute stay disabled until that bar disappears. Once it does, the first real use is Enroll: pick a gallery photo containing exactly one face and store it in the on-device database, then open Identify to match against the live camera.

Device, ABI and license limits you should weigh before committing

The most consequential constraint is the ABI list. The AAR includes native libraries for arm64-v8a and armeabi-v7a only, and the sample app filters to those two. That covers typical phones but excludes x86 and x86_64 builds, which is exactly what emulators use. The README says the emulator is not recommended and, in the system requirements table, not for camera or liveness. So the development loop depends on a physical handset from day one. CI that runs instrumentation tests on an emulator will not exercise this SDK.

The floor for the operating system is API 24, with API 29 or newer recommended. RAM starts at 4 GB, 6 GB or more preferred, and the CPU guidance is four or more cores on a mid-range SoC from around 2019 or newer. These are the README's numbers, not measured results.

The second constraint is that you cannot inspect the engine. The recognition model, the liveness classifier and the template format live inside the AAR. If your compliance process requires reviewing the model or reproducing its training, this repository cannot satisfy it. The README also does not document rollback, versioning of the AAR, or how updates to the binary are delivered. There are no releases listed for the repository, so the AAR's change history is not visible from GitHub. Treat the Drive folder as the distribution channel and plan your own checksum and version pinning around it.

Where FacePlugin's Android SDK is the wrong tool

This SDK is the wrong choice when the face recognition you want is a convenience unlock rather than an identity decision. Android's own face unlock is a platform feature with no enrollment database for you to manage, and the search interest around changing or activating face recognition on a phone is about that feature, not about this SDK. If your product just needs a faster unlock on a handset, you do not need an AAR, a license key or a camera pipeline.

It is also wrong when your application is a web app or a cross-platform UI that only needs a thin native bridge. The README lists sibling repositories for iOS, React Native, Flutter, Ionic Capacitor, Ionic Cordova, Windows and Linux or Docker. Picking the Android repository and wrapping it yourself duplicates work that already exists in a maintained form for those stacks.

Finally, it is wrong if you need server-side matching against a central gallery. The design here is on-device, with the template database living on the phone. The README's Linux and Docker sibling is the repository that matches the server-side shape, and the README does not describe any sync path from the Android on-device database to a backend.

How it compares with ML Kit and other on-device options

Google's ML Kit Face Detection is the obvious alternative for the detection half of this problem, and the difference is scope rather than quality. ML Kit's face detection gives you bounding boxes, landmarks and contours on-device, and it is free to use without a license key. What it does not give you is a face template, a 1:N similarity score against an enrollment database, or an anti-spoofing decision. FacePlugin's SDK bundles all three, plus attributes such as age, gender and emotion, in a single AAR.

That bundling is the trade. You get a complete pipeline with a demo app that runs in about ten minutes once the AAR is in place, according to the README, and you get the copy-paste FaceRecognitionClient helpers so camera and threading work is already done. In exchange you take a binary dependency you cannot read, an offline license tied to your applicationId, and an ABI list that rules out emulators. A team that only needs to locate faces on a bitmap should not pay that cost. A team that needs to decide whether a live person matches an enrolled template is closer to the intended use, and building that from detection primitives alone means sourcing a template model and a liveness model separately.

Maintenance, licensing and what to check before you ship

The repository is not archived, and the last push was on 2026-09-09, so the demo layer is being touched. That says nothing about the AAR, which is not in the repository and has no releases listed, so the engine's own update cadence cannot be judged from GitHub. Plan for the possibility that the demo code and the binary move on different schedules.

The repository's licence is not stated in the README. That matters more than usual for this project, because the runtime is a proprietary binary rather than the Kotlin code you can read. The README describes an offline license mechanism and a bundled LICENSE_KEY for the sample package, which implies commercial terms, but the terms themselves are not in the repository. Read the FacePlugin site and the help center at doc.faceplugin.com before you build a product around it, and get your own legal review rather than relying on the README's framing.

Upgrade cost is concentrated in one place. Because the AAR is downloaded by hand, every engine update is a manual file replacement plus a rebuild, and the README does not document a versioning scheme you can pin against. Budget for storing the exact AAR you shipped and for a regression pass over Enroll, Identify and liveness thresholds after each replacement. The Settings tile exposes camera lens plus identify, liveness, pose and eye-close thresholds, so those are the knobs to re-tune if a new binary shifts behaviour.

Editorial conclusion

Adopt it if you are building a native Android KYC or onboarding flow where biometric data must stay on the handset, and you accept that the recognition engine ships as a binary AAR outside the repository. Do not adopt it if you need to audit or retrain the model, if you cannot use arm64-v8a or armeabi-v7a, or if you expect an emulator workflow. Verify three things first: that the AAR downloads from the linked Google Drive folder, that your applicationId matches the LICENSE_KEY you hold, and that your minimum API level is 24 or higher.

Frequently asked questions

Official sources

1. Faceplugin-ltd/FaceRecognition-Android on GitHub
2. Issues
3. Project website
4. README