FaceAISDK Android: offline face recognition you can put in an APK

The integration is one dependency line

The whole distribution story is one line in your Gradle file, because the SDK is hosted on Maven Central rather than requiring a local AAR or a git submodule:

api 'io.github.FaceAISDK:Android:Version' // UVC protocol cameras also require UVCAndroid dependency

The only configuration note attached to it is that UVC protocol cameras also need the UVCAndroid dependency, which is the first sign of how the project is organised: the core library and the exotic camera path are separate concerns.

The README then states the operating envelope plainly. The SDK supports Android 8 through 16, every function works offline, and no data is uploaded or stored. That last claim is the one that matters most commercially, because it turns a privacy review from an architectural argument into a fact you can verify by watching the network. There is no image leaving the process, no per-user cloud cost, and no dependency on a service staying up.

The repository sits at 1,264 stars and 244 forks with 7 open issues, and the last push was 2026-08-30. The README is bilingual with a Chinese original, and the 2026.07.31 version entry lists a new English language among its changes, which is consistent with a project widening its audience deliberately rather than drifting into it.

Two camera paths, and why the UVC one needs specific hardware

The project structure overview in the README is a module table, and the two entries that matter most for integration are SysCamera and UVCCamera. SysCamera is the system camera on phones and tablets, and the README makes a claim about it that is rare in camera SDK documentation: it works immediately after opening. No reconfiguration, no special permission dance beyond the usual. For a product shipping to consumers on unknown hardware, that is the difference between a feature and a support burden.

UVCCamera is the other path, for UVC protocol USB cameras, and the README frames it as the choice for custom hardware. This is where the project's own requirements get specific: UVC protocol cameras require clear imaging, and the recommended dynamic range is above 105dB.

That number is doing real work in the argument. A UVC camera that does not meet it will feed the recognition model frames with clipped highlights or crushed shadows, and no amount of threshold tuning fixes a frame that lost the information. If you are building a kiosk, a door terminal or a lab bench device around this SDK, that spec line is a procurement requirement rather than a footnote. The same applies to silent liveness, which the README explicitly warns is camera and lighting dependent.

The other three modules are about application structure rather than hardware. verify is 1:1 face detection and recognition plus liveness detection and static face comparison. search is 1:N face search with face library management, which the README spells out as CRUD. addFace is shared between the 1:1 and 1:N paths, handling both adding faces and getting feature vectors through the SDK camera, so enrollment logic is written once rather than twice.

Liveness in two forms, and a threshold that moves

Liveness detection is where this SDK separates itself from a plain recognition library, and it offers two distinct mechanisms. Action liveness asks the user to do something: mouth opening, smiling, blinking, head shaking, head nodding. Each of those is an explicit instruction in your UI, which is a well-understood pattern and easy to explain to a user.

Silent liveness asks for nothing. No prompt, no movement, the user only looks at the camera. That is a much better experience for a door or a check-in point, and it is a much harder engineering problem, which is why it is worth noticing how the project reports on it.

The 2026.07.31 and 2026.08.01 releases both carry a silent liveness threshold range of 0.85 to 0.95, and both repeat the same caveat: actual performance varies with camera and lighting, adjust based on scenario. A vendor publishing a threshold range instead of a single number is telling you two useful things. First, the acceptable cut-off is scenario dependent, so a kiosk in a lit hallway and a terminal in a dim stairwell are not the same tuning problem. Second, the project expects you to tune, which means the raw score is exposed rather than reduced to a pass or fail inside the SDK.

The same two releases also list a silent liveness update, a reduced SDK size, and Android 17 compatibility preprocessing marked as to be verified. Shipping unverified compatibility work in the same release as the feature changes is normal commercial SDK practice, but it is also a signal: the library is tracking new Android versions ahead of your app's target SDK, which removes a class of work you would otherwise own.

1:1 and 1:N, and the scenarios the README claims for each

The README splits its scenarios by verification model, and the split is instructive because the two have genuinely different engineering shapes.

The 1:1 list is mobile attendance, app password-less login, face authorization, face unlock and patrol check-in verification. Each of these is a comparison against a single enrolled identity, so the work is enrollment quality, threshold selection and a good capture experience rather than search performance.

The 1:N list is residential access control, company access control, smart locks, smart campus, robots, smart home, community and hotels. These all share the same underlying requirement, which is matching one face against a library of many. The README links this to a dedicated 1:N and M:N introduction document, and the search module is where the face library CRUD lives, which tells you the library is a first-class object in the SDK rather than an array you manage yourself.

The M:N case, comparing a group in a camera frame against a group in a library, is the reason the scenario list includes robots and smart campus. That is a different problem from a single head at a door, and it is where you would expect the README to discuss detection accuracy under crowding. It does not, at least not in the README as published. The documentation burden for this project sits in a PDF product and API description under Document/, not in the repository itself, so budget time to read it before estimating the 1:N work.

A multi-platform shop with one shared idea

The repository tree is small, and its smallness is informative. There is a FaceSDKLib sub-module where all features are demonstrated, a Launcher directory for the sample app, a Document directory holding the PDF product description, both README.md and README_CN.md, and the usual Gradle scaffolding including gradle.properties and a gradlew wrapper.

There is no library source directory beyond FaceSDKLib in the visible tree, no test directory, and no CI configuration beyond a .github entry. Combined with the fact that the demo APK is distributed through a third-party QR code page rather than the releases section, this reads as a commercial SDK whose implementation is closed and whose samples are the documentation. That is a completely normal shape for this category of product, and it changes what you evaluate: you are evaluating a binary artifact and its vendor responsiveness, not a codebase.

The responsiveness signal is reasonable. Three releases in mid-2026, each with dated entries, and the most recent is tagged 2026.08.11 with the body HarmonyOS Dev Ready. That single-word release is a signal about where the effort is going next, and if you are not building for HarmonyOS it costs you nothing while telling you the platform story is not finished.

The sibling repositories are the other piece: iOS, Flutter, uniApp UTS and React Native all have their own FaceAISDK repositories. Whether these share a native core or reimplement the logic is not something the README says, so treat cross-platform parity as something to verify with a test on each platform rather than an assumption from the link list.

What to check before you commit

Three gaps deserve attention before this goes into a product, and none of them are hidden.

The first is licensing. There is no licence file and no licence field on the repository, which for an SDK you intend to ship inside a commercial application is a question for the vendor rather than a detail. Face recognition is also regulated differently depending on where your users are, so the compliance posture of a closed binary inference engine is something your legal team will want described rather than inferred from a README.

The second is model provenance and accuracy reporting. The README describes what the SDK does and how to call it, but says nothing about which network architecture backs recognition, how many faces it can match reliably, or what its false accept and false reject rates look like on a population that resembles your users. For 1:1 unlock you can partly substitute your own enrollment discipline for that data. For 1:N access control you cannot, and a project that publishes a liveness threshold range but no matching benchmarks is leaving the most important number undocumented.

The third is the documentation format. The API reference is a PDF, which is fine for reading once and poor for searching while integrating. Budget an afternoon for it rather than assuming you can grep it.

What you get in return is real. Offline inference removes both the bandwidth dependency and the per-call cost that make cloud recognition expensive at scale. Silent liveness removes the prompt from the user experience. The system camera path claims to work on opening, which is most of the integration work already done. Android 8 through 16 is a wide device range for a single artifact, and the multi-language sibling repos mean a Flutter or React Native product does not have to go native to use it.

Editorial conclusion

FaceAISDK_Android is worth evaluating if your product needs face recognition inside the app process on hardware you do not fully control, because the combination it offers is specific: offline inference, silent and action liveness, both 1:1 and 1:N search, and system camera plus UVC USB camera support in one artifact on Maven Central. The specific first step is to add the Android artifact to a single activity alongside the FaceSDKLib module and run the 1:1 path on the front camera of a real mid-range phone, because silent liveness accuracy varies with camera and lighting and cannot be judged from a development device. Before committing, note what the repository does not give you: no declared licence field, no hosted API documentation, and a compatibility claim for Android 17 that the project itself marks as to be verified. Those three gaps are what separate this from a component you can adopt without a legal and procurement conversation.

Frequently asked questions

Official sources

1. FaceAISDK/FaceAISDK_Android on GitHub
2. Issues
3. README
4. Releases