BlinkID for Android: a licensed SDK that reads IDs through the camera
Everything you need to add AI-driven ID scanning into your native Android app.
At a glance
- What is it?
- BlinkID is Microblink's closed-source Android SDK for scanning identity documents and returning structured fields. It is a commercial product with a per-app licence key, and the free tier is a trial, not an open source licence.
- Who is it for?
- Adopt BlinkID if you are building a native Android onboarding or KYC flow, you can accept a closed-source dependency, and you can obtain and manage a licence key bound to your application ID. Do not adopt it if you need a permissively licensed library, if you cannot ship Google Play services or a large native binary, or if you only need MRZ parsing from images you already have.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem BlinkID addresses, and the audience it assumes
Extracting fields from an identity document is a pipeline problem: detect the document in a camera frame, find the machine readable zone or barcode, correct perspective and lighting, run OCR or decoding, then reconcile conflicting values. BlinkID packages that pipeline as a binary SDK for native Android apps. The README describes it as a solution for "secure document scanning and extraction", and the repository topics list KYC, onboarding, MRZ, PDF417 and identity documents, which tells you the intended buyer is a team building an identity verification step inside its own app.
The audience is narrower than the topic list suggests. BlinkID is not a library you drop into a side project. Initialization requires a licence key, and the README states the licence is bound to the application ID of your app. That single constraint shapes everything: this is a product for teams that can register with Microblink, obtain a key, and keep that key aligned with each build variant they ship. If your app ID changes between debug and release, or you ship several flavours, key management becomes part of your build configuration rather than an afterthought. The supported document list and the full set of result fields live on a separate documentation page, so the repository alone does not tell you whether a specific national ID or passport is covered.
How the SDK is structured: SDK instance, scanning session, result object
The architecture visible in the README has three layers. At the bottom is BlinkIdSdk, obtained from BlinkIdSdk.initializeSdk, a suspend function that takes a Context and a BlinkIdSdkSettings holding the licence key. It returns a result wrapper, and the README's example branches on isSuccess, calling getOrNull() for the instance and exceptionOrNull() for the failure path. Initialization is therefore an explicit, fallible step you handle in a coroutine, not a static singleton that throws at first use.
In the middle sits the scanning session, driven either by the BlinkIdCameraScanningScreen composable or by BlinkIdScanActivity for Java and View-based apps. The composable takes the SDK instance plus four settings objects: BlinkIdUxSettings, UiSettings, CameraSettings and BlinkIdSessionSettings, along with callbacks for success, cancellation and an optional per-frame hook. That frame callback is documented as being for debugging, analysis and advanced workflows, and the README says it is not required for basic scanning.
At the top is BlinkIdScanningResult. The README separates its contents into general results and section results. General results merge each data point from the most reliable source, with a stated priority order: barcode first, then MRZ, then visual. Section results keep the per-side, per-source data separate, and each source is only present if the document carries it and your scanning settings allow it. That priority order is the most consequential design detail in the whole document. It means a barcode field will win over an OCR read of the same field, which is usually right for PDF417 on a US driver licence but is an assumption you should test against your own document mix.
Getting it running: dependency, licence key, and the composable call
The dependency is published on Maven Central. You add mavenCentral() to your repositories list, then declare implementation("com.microblink:blinkid-ux:8001.0.0") in the module-level build.gradle or build.gradle.kts. Note the artifact name: blinkid-ux, not blinkid-android. The README also mentions a blinkid-core package in its KDoc links, and one sample app avoids the UX library entirely, so the UX and core layers are separable.
The repository ships three sample apps under a BlinkIDSample folder: sample-app for the Compose UX, java-sample-app for the BlinkIdScanActivity path without Compose, and direct-api-sample-app for scanning images you obtained elsewhere. Open the BlinkIDSample folder directly in Android Studio rather than cloning and guessing at module structure.
Initialization looks like this, taken from the README: call BlinkIdSdk.initializeSdk(context, BlinkIdSdkSettings(licenseKey = "your_license_key")) from a coroutine, then branch on isSuccess. Rendering the scanner means calling BlinkIdCameraScanningScreen with the SDK instance, the four settings objects, and onScanningSuccess, onScanningCanceled and onFrameProcessResult callbacks. The success callback receives a BlinkIdScanningResult. For the Java path, the README points at BlinkIdScanActivity instead, and the direct API sample shows how to skip the camera flow when you already hold document images.
Device requirements and the resource download problem
Two hard requirements appear in the README. The SDK needs Android API level 24 or newer, and the camera preview resolution must be at least 1080p. The README explicitly warns that preview resolution is not the same as video recording resolution, which is the kind of distinction that catches teams testing on a device whose recorder is 1080p but whose preview stream is lower. If your minimum supported device cannot produce a 1080p preview, scanning will not work reliably regardless of what the rest of your app supports.
Camera selection is configurable through CameraSettings, including choosing between CameraLensFacing.LensFacingBack and CameraLensFacing.LensFacingFront, and selecting higher or lower resolutions. Front-facing selection matters for the selfie-side flows some onboarding journeys use, though the README does not describe any face-matching capability, so do not read that into it.
The part that deserves more attention than the README gives it is resource management. The SDK uses downloadable resources, and the README documents three modes: configuring resources, pre-bundling them into your app, and over-the-air delivery. Each has a different cost. OTA keeps your APK smaller but makes first-run scanning depend on a network fetch, and the README has a separate section on clearing cached resources, which implies the cache can grow and that you may need a strategy for evicting it. Pre-bundling removes the network dependency at the cost of app size, and the README has a dedicated section on SDK size for exactly that reason.
Where BlinkID is the wrong choice
The licence is the first limitation and the repository does not resolve it cleanly. The metadata reports NOASSERTION, which means GitHub could not match the licence file to a known identifier. The README's own framing is commercial: a valid licence key is required, the free trial comes from the Microblink Developer Hub after registration, and the key is bound to your application ID. Nothing in the supplied material describes an open source grant. Treat this as a proprietary SDK with a trial option until you have read the actual licence terms, and note that this article is not legal advice.
Second, the dependency is a binary. You cannot patch the document detection or OCR behaviour if it misreads a document type you care about. Your only levers are the settings objects and the document support list, which lives outside the repository. If your document mix includes something the supported list does not cover, the SDK will not grow that support on your schedule.
Third, the 1080p preview floor excludes a slice of low-end and older hardware. Combined with the API 24 minimum, that narrows your addressable device range in markets where cheap Android hardware dominates. If your onboarding funnel targets those markets, measure the exclusion before you commit.
Fourth, if all you need is MRZ parsing from images your backend already receives, the full camera pipeline plus a licence key plus OTA resource management is more machinery than the problem requires.
Alternatives and how their approach differs
The clearest alternative visible in this repository's own material is the direct API path, demonstrated by direct-api-sample-app. It uses the same SDK but skips the document scanning process and the blinkid-ux library, which the README recommends when you obtain document images through other methods. That is not a different vendor, but it is a genuinely different architecture: you own capture, and the SDK only performs extraction. If your app already has a camera flow you like, this removes the UX layer and its customization surface entirely.
For teams that cannot accept a proprietary dependency, the realistic alternative class is open source OCR and barcode decoding composed by hand: a PDF417 or MRZ decoder for the structured zones, plus a general OCR engine for the visual zone, plus your own document detection and perspective correction. The difference is not just licence. BlinkID's value is the reconciliation step, the barcode-over-MRZ-over-visual priority that produces one merged field set. Building that yourself means writing conflict resolution for every document type you support, and testing it against real captures. That is the work you are buying, and it is also the work you keep paying for if you build it.
A third option is a server-side verification service. It moves the extraction off the device, which sidesteps the 1080p preview requirement and the app-size cost of pre-bundled resources, at the price of uploading document images and accepting the latency of a round trip.
Maintenance, versioning and upgrade cost
Version numbers here are large and move quickly. The supplied releases show v8001.0.0 in July 2026, then v8001.0.1 and v8001.0.2 within days of each other in late August 2026, and the README's dependency example pins 8001.0.0. The README also links a migration guide from v7 to v8000, which tells you the major version boundary was a breaking change significant enough to warrant its own documentation page. Plan for migration work at major boundaries rather than assuming drop-in upgrades.
Because the SDK is distributed as a Maven artifact with a licence key bound to your application ID, upgrades interact with your build configuration. A new version can change initialization behaviour or settings object shapes, and the README's own API surface has already moved from an activity-based flow to a Compose-first one while keeping BlinkIdScanActivity for Java. Teams on the Java path are on a supported but clearly secondary track.
Resource handling adds ongoing cost that is easy to underestimate. If you choose OTA delivery, you own the first-run network dependency and the cache growth that the clearing-cached-resources section exists to address. If you pre-bundle, you own the app size and re-ship resources with every SDK upgrade. Neither is free, and the choice is a product decision about your install size and your offline behaviour, not a build detail.
Editorial conclusion
Adopt BlinkID if you are building a native Android onboarding or KYC flow, you can accept a closed-source dependency, and you can obtain and manage a licence key bound to your application ID. Do not adopt it if you need a permissively licensed library, if you cannot ship Google Play services or a large native binary, or if you only need MRZ parsing from images you already have. Before committing, verify your trial key works against your release application ID, confirm the camera preview path on your lowest-target device reaches 1080p, and read the licence terms for redistribution and OTA resource hosting.
Community notes