FacePlugin Face Recognition SDK for Android: an AAR-first demo repo with an offline licence

The repo is a demo shell, and the engine is not in it

The single most important thing to understand before cloning is what is and is not in the repository. The README states plainly that libfacesdk/facerecognitionsdk.aar is empty on GitHub because the binary is too large. The runtime you actually integrate is a file you download separately from a Google Drive folder. Everything else here, the six home tiles, the CameraX plumbing, the Kotlin helpers under app/.../kit/, is a sample that exercises that binary. So the repository is documentation-by-example: it shows you the calling convention for a library you cannot read. That has a direct consequence for evaluation. You can judge the API surface and the integration ergonomics from the Kotlin, but you cannot judge the model, the training data, or the matching algorithm from anything in this repo. If your procurement process requires source review of the recognition engine, this repository will not satisfy it, and no amount of reading the demo will change that.

What the six tiles actually cover

The demo exposes Enroll, Identify, Capture, Attribute, Settings and About. Enroll takes a gallery photo and requires exactly one face, then writes a template into an on-device database. Identify runs a live 1:N camera match and, per the README, stops on the first hit, with 2D liveness applied. Capture uses an oval coach to produce a still image with attributes attached, and offers optional enrollment from that still. Attribute runs gallery analysis and returns landmarks, liveness, pose, quality, age, gender and emotion. Settings holds the camera lens choice plus the identify, liveness, pose and eye-close thresholds. The README also lists 14-point landmarks, template extraction, 1:N similarity and an offline licence as features that sit beneath those tiles. The stop-on-first-hit behaviour in Identify is worth noting: it is a deliberate latency choice for 1:N search, and it means the tile does not report how many other enrolled identities were close to the threshold. For a demo that is fine. For a production identity system, a single nearest match with no visibility into runner-up scores is a thin basis for tuning.

Getting it running: clone, drop the AAR, run on a physical phone

The README gives a short path. Clone the repository, download facerecognitionsdk.aar from the linked Google Drive folder, and place it directly in libfacesdk/ next to libfacesdk/build.gradle. The documented commands are: git clone https://github.com/Faceplugin-ltd/FaceRecognition-Android.git followed by cd FaceRecognition-Android. From there you open the folder in Android Studio and run on a physical phone. The README is explicit that the emulator is not recommended, and the system requirements table repeats that the emulator is not for camera or liveness work. The home screen shows a status bar reading Loading native SDK... and the Enroll, Identify, Capture and Attribute tiles stay disabled until that bar disappears. That status bar is your first integration signal: if it never clears, the AAR is missing, misplaced, or the licence is wrong. A demo licence is already committed in the repo as LICENSE_KEY for the applicationId com.faceplugin.facerecognitionsdk, and the README tells you to request a new key only if you change that applicationId. Keep the applicationId as-is if you want the shipped key to work.

Licence, ABIs and the constraints that bite first

The licence model here is offline and bound to the application identifier. That is convenient for air-gapped and privacy-first deployments, and it is also the first thing that breaks during a rebrand or a white-label build. Change applicationId without requesting a new key and the SDK will not validate. The licence identifier is not stated in the material provided, so treat the terms as unknown until you read them on the vendor site. On the binary side, the AAR bundles native libraries for arm64-v8a and armeabi-v7a only, and the sample app filters to those two ABIs. That rules out x86 and x86_64 emulators and any x86-based device or CI runner that tries to load the native code. The stated minimum is API 24 (Android 7.0), with API 29 or newer recommended, 4 GB of RAM minimum and 6 GB or more recommended, a 4-core CPU and a front camera at 720p or 1080p. The README's reference point for CPU is a mid-range SoC from around 2019 or newer. Those are the vendor's stated floors, not measured results. The repository has no release tags retrieved, so there is no versioned changelog to tell you what changed between AAR drops. You are tracking a binary by download link, which makes reproducible builds harder than a Maven coordinate would.

Where this is the wrong tool

Three cases stand out. First, anything that needs to run in an emulator-based CI pipeline. The ABI filter and the explicit emulator warning mean your automated tests either need physical devices attached or they need to mock the SDK entirely, which leaves the recognition path untested. Second, anything requiring model transparency or retraining. Because the engine arrives as an AAR and the repository contains only the demo, there is no path here to swap the model, inspect thresholds at the feature level, or reproduce a similarity score independently. Third, multi-tenant or white-label products. Every distinct applicationId implies a separate licence request, which turns a routine build variant into a vendor interaction. There is also a subtler limitation in the demo itself: the Attribute tile is described as gallery analysis, and the README does not state accuracy figures, demographic breakdowns, or false-accept and false-reject rates for liveness or matching. For a component used in KYC, the absence of published error rates in the repository is a gap you will have to close with your own acceptance testing on your own device fleet.

How it compares to rolling your own with ML Kit and TFLite

The obvious alternative for an Android team is assembling the pipeline from Google's ML Kit face detection plus a TensorFlow Lite face embedding model, with a custom liveness check. The difference in approach is not accuracy on paper, it is where the work sits. ML Kit gives you detection and landmarks as a supported, versioned dependency, and you write the enrollment store, the 1:N search, the threshold tuning and the anti-spoofing logic yourself. FacePlugin inverts that: the matching, liveness, pose, quality, age, gender and emotion outputs all arrive pre-built behind one AAR, and your work is integration plus threshold configuration in the Settings tile. The trade is control for time. A self-built stack is auditable, retrainable and free of per-application licence keys, but it puts the anti-spoofing problem, which is the hard part, entirely on your team. FacePlugin's own product list shows the same engine offered across iOS, React Native, Flutter, Ionic Capacitor, Ionic Cordova, Windows and Linux/Docker, so if you need cross-platform parity the single-vendor route has a real consistency argument. If you only ever ship Android and you already have ML experience in-house, the self-built route keeps the model under your control.

Maintenance cost and what to check before you commit

The maintenance picture is shaped by the delivery mechanism. Upgrades mean re-downloading facerecognitionsdk.aar and replacing the file in libfacesdk/, with no release notes retrieved in the repository to diff against. Budget for a regression pass on your own devices after every AAR swap, because the demo's threshold defaults in the Settings tile are the only tuning surface the README documents. Pin the AAR in your own artifact repository rather than pulling from a shared Drive folder, so a build is reproducible and a vendor link change does not break CI. On licensing, the repository does not state a licence identifier, so the terms governing redistribution inside a shipped APK are not determinable from this material; read the vendor's SDK licence before you ship, and treat a change of applicationId as a licensing event rather than a build-config change. The concrete first step is to confirm the AAR downloads, place it at FaceRecognition-Android/libfacesdk/facerecognitionsdk.aar, run the demo on an arm64-v8a phone, and watch whether the Loading native SDK... bar clears.

Editorial conclusion

Adopt it if you are building an Android KYC or access-control flow that must run fully on-device and you accept a closed binary with a per-application licence. Do not adopt it if you need to audit or retrain the model, if you target x86 emulators or CI without physical hardware, or if you cannot obtain the AAR. Before committing, verify three things: that facerecognitionsdk.aar downloads from the Google Drive folder and matches the arm64-v8a and armeabi-v7a filter, that your applicationId matches the LICENSE_KEY you hold, and that your minimum API level is 24 or higher.

Official sources

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