kamera_testing 1.0.0-beta1

Replay test kit for kamera. A thin controller that drives the native KameraReplay facade over a control MethodChannel for E2E tests. Pixels never cross the bridge — only fixture ids and the machine-re [...]

Changelog

The single changelog for kamera. All four packages — Android (com.usesmileid:kamera + -mlkit / -huawei), iOS (Kamera.xcframework), Flutter (kamera), and React Native (@smileid/kamera) — are versioned and released in lockstep: every release publishes all four at the same version, no matter which platform the change touched. There are no per-package changelogs; record every user-facing change here under ## Unreleased.

The version is driven by the root VERSION file (bump with scripts/set-version.sh x.y.z); a CI gate keeps every package pinned to it.

Format: Keep a Changelog · Versioning: Semantic Versioning.

Unreleased

Added

• iOS: kamera is now consumable through Swift Package Manager, from the public smileidentity/kamera-spm distribution repo — .package(url: "https://github.com/smileidentity/kamera-spm", exact: "<version>"), with Kamera, KameraVision and KameraTesting as separate products. Previously the xcframeworks were only attached to this repo's releases, so every consumer hand-vendored the zips. Both the manifest and its releases are produced by kamera-ios/Scripts/publish_spm.sh, mirroring how the v12 iOS SDK publishes to ios-spm: production versions land on main, pre-releases on snapshot. The GitHub releases on this repo are unchanged, so existing consumers keep working.

Changed

• Publishing is now one workflow per platform — publish-android.yaml, publish-ios.yaml, publish-flutter.yaml, publish-expo.yaml — the way each Smile ID SDK repo owns its own publish.yaml. release.yml and snapshot.yml are gone; republishing one platform no longer reruns the other three. Android and iOS each take a channel input (release or snapshot); Flutter and Expo are release-only, as they already were.

  Order matters and nothing enforces it: run publish-ios first (it cuts the GitHub Release), then publish-android, then the wrappers — they vendor the xcframeworks from that release by version and wait on Maven Central. The old single workflow cut the tag last, only once every platform had published, so this trades that atomicity for independence.

• Flutter (kamera) and React Native (@smileid/kamera) wrapper snapshots are no longer published to pub.dev / npm from snapshot.yml; the v12 Flutter/RN SDKs consume the wrappers directly from a branch of this repo (kamera-flutter/, kamera-react-native/). Android (-SNAPSHOT on Maven Central) and iOS (prerelease xcframework Release) snapshots are unchanged. Registry publishing is blocked — Flutter's 0.1.0-SNAPSHOT.N is semver-below the published stable kamera 0.1.0, and the CI npm token lacks publish rights for @smileid/kamera.

• Published packages now hide their implementation (design 27): the Android AAR ships with com.usesmileid.kamera.internal.* obfuscated by R8 (public API kept); the iOS xcframework is built with local symbols stripped and no dSYM bundled; and the React Native package publishes a minified dist/ bundle instead of raw source (the codegen spec files stay readable, as RN codegen requires). dSYMs are never shipped in any package.

Fixed

• Android: KameraSession.release() is now terminal — a start() issued after it is a no-op. Release already shut the analysis executor down, so a restarted session could never serve frames, but it did re-register the thermal status listener. That listener is a binder stub the system holds as a JNI global root, and the matching unregister only runs inside release(), so a start arriving after release left one nothing would ever remove — pinning the session and, through its lifecycleOwner, the host that constructed it. Hosts that tear the camera down while a start is still in flight saw a leaked activity per capture screen.

• React Native (@smileid/kamera) on Android: the preview no longer renders black. The view manager attached the session to a preview view only at createViewInstance, but React mounts the view while rendering the tree — normally before JS calls start() — so on the common ordering there was no session to attach and nothing to attach it later. The same gap broke the second flow on a screen that survives a release()/start() cycle: the view stayed bound to the released session. Every mounted preview view is now tracked (weakly, so a dropped view cannot leak its activity) and attached whenever a session becomes current, so mount-before-start, start-before-mount, and repeated sessions all end with a live preview.

• React Native (@smileid/kamera): the generated TurboModule spec now lands in the package KameraModule imports. codegenConfig.android.javaPackageName was only honoured by the Gradle plugin, not by the CLI behind npm run codegen:android — which has no such flag — so the two codegen paths emitted NativeKameraSpec into different packages and a consumer build failed with Unresolved reference 'NativeKameraSpec'. Dropping the override puts both on React Native's default com.facebook.fbreact.specs, which is what the committed tree and the import already used.

• React Native (@smileid/kamera): a consuming app on the new architecture can now configure CMake. The Android glue declares codegenConfig, so autolinking always emits add_subdirectory(<lib>/android/build/generated/source/codegen/jni) and links react_codegen_KameraSpec — but nothing generated that directory, because the glue applied only com.android.library. Every native Android build failed at configure with "not an existing directory", then "Cannot specify link libraries for target react_codegen_KameraSpec which is not built by this project". The glue now applies com.facebook.react when it is on the classpath, so the spec is generated against the consumer's own React Native version. The node-free standalone glue build is unaffected — the plugin is absent there and the committed codegen still serves it.

• Flutter (kamera_testing): an app using the replay kit alongside kamera can now resolve its Swift packages. Both packages declared a binary target named Kamera, and SPM requires target names to be unique across the whole package graph, so resolution failed outright with "multiple packages ('kamera', 'kamera_testing') declare targets with a conflicting name: 'Kamera'". The test kit no longer declares one: its glue needs no Kamera symbol (KameraReplay and FixtureRegistry are KameraTesting's own API), and KameraTesting's link-time dependency resolves against the copy kamera vends. fetch_xcframeworks.sh for the test kit now needs only KameraTesting.

• The published Flutter (kamera) and React Native (@smileid/kamera) wrappers now resolve their native -SNAPSHOT dependency from the Maven Central snapshots repo. In -SNAPSHOT mode the Android glue injected only mavenLocal() into the host build, so an external consumer of the published wrapper tried to resolve com.usesmileid:kamera:<x.y.z-SNAPSHOT> from an empty ~/.m2 and the build failed; the snapshots repo (where snapshot.yml publishes the artifacts) is now injected alongside mavenLocal.

0.1.0

• Initial pre-release of the kamera camera SDK, published in lockstep across Android, iOS, Flutter, and React Native.