jenly1314/MLKit: a Kotlin wrapper that puts Google ML Kit behind CameraScan

The gap this fills between Google's ML Kit SDK and a working camera screen

Google publishes ML Kit as a set of vision APIs, and the documentation for each one describes how to build a detector, feed it an input image, and read the result. What it does not hand you is the part where frames arrive from a camera, get rotated and converted, get passed to the right detector at a rate the device can sustain, and come back as something you can draw on screen. That glue is what this repository packages. Each feature lives in its own Gradle module, and each module supplies two things: an Analyzer class that adapts the ML Kit detector to a common analysis interface, and a BaseCameraScanActivity or BaseCameraScanFragment subclass that you can extend to get a working preview screen. The README's own framing is that the library brings Google's machine learning knowledge into an app so that, in its words, you can implement the feature you want in a few lines of code. The audience is Android developers who want a vision feature without assembling the camera pipeline, and who are content to sit on top of Google's hosted models rather than train or ship their own.

Module layout: one artifact per vision feature, plus a shared common layer

The repository is split so that you only pay for what you use. mlkit-common is the required artifact; the README marks it as mandatory and describes it as the layer between the camera and the feature modules, holding the shared business logic that keeps each feature module small. On top of it sit optional modules: mlkit-barcode-scanning, mlkit-face-detection, mlkit-face-mesh-detection, mlkit-image-labeling, mlkit-object-detection, mlkit-pose-detection, mlkit-pose-detection-accurate, mlkit-segmentation-selfie, and mlkit-text-recognition. The accurate pose variant is documented as carrying a larger dependency, which is the trade-off you would expect from a heavier model. There is also an app module, which is a demo application rather than a library, and a prebuilt release APK linked from the README for trying the features without building anything. Two modules that existed in the 1.x line are gone: mlkit-camera-core was removed and replaced by an external dependency on CameraScan, and the ViewfinderView that used to live inside mlkit-barcode-scanning was split out into its own repository. That split is the single most important structural fact about the 2.x line.

How a frame becomes a result: CameraScan as the pipeline, Analyzer as the adapter

From 2.0.0 onward the camera side of this project is not implemented here at all. The README states that the 2.x implementation uses CameraScan as its base library and that understanding CameraScan's usage is sufficient to use every submodule in MLKit. So the data flow runs through three layers: CameraX supplies preview frames, CameraScan handles the preview and the analysis loop, and the per-feature Analyzer receives frames and calls into the corresponding Google ML Kit detector. The README's core class table makes the mapping explicit. Barcode scanning maps to BarcodeScanningAnalyzer with BarcodeCameraScanActivity or QRCodeCameraScanActivity; face detection to FaceDetectionAnalyzer and FaceCameraScanActivity; face mesh to FaceMeshDetectionAnalyzer and FaceMeshCameraScanActivity; image labeling to ImageLabelingAnalyzer and ImageCameraScanActivity; object detection to ObjectDetectionAnalyzer and ObjectCameraScanActivity; pose detection to PoseDetectionAnalyzer and PoseCameraScanActivity, with AccuratePoseDetectionAnalyzer and AccuratePoseCameraScanActivity for the accurate variant; selfie segmentation to SegmentationAnalyzer and SegmentationCameraScanActivity. The practical consequence is that swapping features means swapping an Analyzer and an Activity base class, not rewriting a camera loop. It also means the interesting camera behaviour (resolution selection, frame throttling, lifecycle handling) is maintained in a different repository than the one you are reading.

Getting it into a build: repositories, artifacts and the compileSdk floor

The README gives a two-step Gradle setup. First, add mavenCentral() to the repositories block in the project-level build.gradle or in settings.gradle. Second, add dependencies in the module-level build.gradle, starting with the mandatory common artifact and then whichever feature modules you need, all pinned at the released version. The README's example uses 2.5.0, the most recent release listed. The lines read implementation 'com.github.jenly1314.MLKit:mlkit-common:2.5.0' for the common layer, then entries such as implementation 'com.github.jenly1314.MLKit:mlkit-barcode-scanning:2.5.0', mlkit-face-detection, mlkit-face-mesh-detection, mlkit-image-labeling, mlkit-object-detection, mlkit-pose-detection, mlkit-pose-detection-accurate, mlkit-segmentation-selfie and mlkit-text-recognition, each marked optional in the README. There is a hard version constraint that is easy to miss: v2.4.0 and above require compileSdk 35 or higher, v2.1.0 and above require compileSdk 34 or higher, and v2.0.0 and above require compileSdk 33 or higher. If your compileSdk is below 33, the README directs you to the 1.x branch instead. The manifest metadata in the README also gives a minimum API level of 23.

The 1.x to 2.x migration is a package rename, not a rewrite

If you are already on 1.x, the upgrade path is narrow but not free. The README says the main 2.x usage is broadly similar to 1.x with some details changed, and that the significant differences are the two extracted libraries: mlkit-camera-core replaced by CameraScan, and ViewfinderView moved out of mlkit-barcode-scanning into its own repository. Because those libraries are now maintained separately, their package names changed, and the README is explicit that this is the thing to watch. Its guidance is that most of the upgrade consists of updating import statements. That is a reasonable claim for a wrapper library, but it does mean a 1.x codebase will not compile against 2.x until every reference to the old camera-core and viewfinder packages is found and repointed. The README also notes that 1.x users should consult the v1.x branch rather than the main one, which is a hint that the main branch documentation no longer describes the older API surface.

What you are actually depending on, and where that bites

The most consequential limitation is architectural rather than technical. This project is a wrapper, so the recognition quality, model size, supported languages and update cadence are all determined by Google's ML Kit, not by this repository. The README's own module descriptions defer to Google's documentation for each capability, and the object detection entry carries a concrete constraint from that source: a single image can detect at most five objects. Because the camera layer now lives in CameraScan, a bug in preview handling or frame throttling is fixed in a different repository on a different release schedule, and you will be tracking two version numbers instead of one. The dependency on Google Play services is also worth stating plainly for anyone who has not used ML Kit before: this is not an offline, self-contained model you can retrain or audit. If your app ships to devices without Play services, or your requirements include a custom model, the wrapper does not help you. The README does mention that ML Kit exposes APIs for using custom TensorFlow Lite models in a mobile app, but that is a capability of the underlying SDK, and this repository's modules are organized around the stock vision features.

Where a general vision SDK or a raw detector call is the better fit

The honest alternative is to use Google's ML Kit directly and write your own camera analysis loop, or to use a cross-platform vision SDK that covers Android and iOS from one codebase. The difference in approach is real. Calling ML Kit directly gives you control over the frame pipeline: you decide when to throttle, how to crop, whether to run detection on a downscaled bitmap, and how results are drawn. That control matters when you need to tune latency on low-end devices or when your UI does not resemble a full-screen scanner. The wrapper's value is the opposite: it removes those decisions by giving you BarcodeCameraScanActivity or PoseCameraScanActivity and letting you extend it. If your screen is a standard scanner overlay, that is a good trade. If your detection runs on a still image the user picked from the gallery, or on a video file, or inside a custom composable layout, you are paying for a camera integration you will not use. A cross-platform SDK, meanwhile, solves a problem this repository does not attempt: it does not offer an iOS counterpart, so a team shipping both platforms ends up with two different vision stacks.

Maintenance, licensing and what to check before you commit

The repository is Apache-2.0 licensed, which permits commercial use and modification; the usual obligations around attribution and notice files apply, and this is not legal advice, so read the licence text yourself if your organisation has a policy. On maintenance, the release history shows 2.5.0 in June 2026, 2.4.0 in March 2026 and 2.3.0 in January 2025, so the gap between 2.3.0 and 2.4.0 was roughly fourteen months. That is a slow but not abandoned cadence, and it means you should not expect a fix for a CameraScan interaction issue to land quickly. The compileSdk floor is the upgrade cost that will actually interrupt you: moving from 2.3.0 to 2.4.0 or later raises the requirement to compileSdk 35, which for many teams means bumping the Android Gradle Plugin and Gradle together. Verify your compileSdk against the version you pin, confirm that mlkit-common plus only the feature modules you need are in your dependency graph, and if you are coming from 1.x, grep your imports for the old camera-core and viewfinder package names before you start the upgrade rather than after the build fails.

Editorial conclusion

Adopt this if you are building an Android app that needs barcode scanning, text recognition, face or pose detection against a live camera feed, and you want the analyzer wiring already done. Do not adopt it if you need iOS, a desktop build, an offline model you can retrain, or a project that does not depend on Google Play services. Before committing, verify three things against your own build: that your compileSdk meets the v2.4.0 requirement of 35 or higher, that the mlkit-common artifact plus only the feature modules you actually use are the ones you pull in, and that the CameraScan and ViewfinderView package names match what your existing code imports if you are migrating from 1.x.

Official sources

1. jenly1314/MLKit on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases