Check each module's specific conditions
ak-secure-storage saves, reads, and clears credentials through Android Keystore, iOS Keychain, and HarmonyOS Asset Store. It has no Web implementation or ordinary-storage fallback. HarmonyOS values are limited to 900 UTF-8 bytes. Test absent keys, reads after deletion, and unavailable secure storage.
ak-push handles native push integration and depends on ak-permissions. ak-oauth handles provider authorization and one-time credentials, with capabilities determined by platform and build configuration. Both require project-owned provider accounts, domains, or signing material. Copying their source does not establish channel connectivity.
ak-interactive-captcha renders click, slide, drag, and rotation challenges and returns answers to the caller for submission. The server verifies them; the component does not provide an independent bot-protection service. Expired or replaced challenges must discard old answers.
Evaluate a push requirement
Suppose a technician needs an assignment notification. First ensure the work order is available after sign-in, then decide which changes need system push. A user who declines notification permission must still be able to find the business record, with the interface explaining that notifications are disabled.
During integration, confirm that ak-permissions accompanies the main module, select the Android push build variant, and bind the backend channel to the correct App. Client tokens must reach authenticated endpoints that associate the user and device. Check old bindings when a token changes.
Acceptance includes permission denial, an invalid token, opening a notification before sign-in, and opening a record the user can no longer access. A notification identifier locates a resource; the destination must read it with authorization again. Sensitive payload data cannot become trusted merely because it arrived in a notification.
This assignment scenario illustrates adoption work. The source package contains no work-order application. Confirm displayed notifications on real devices in your project environment.
Compare an archive with its source
Official ZIP files are archived from a pinned public commit. They retain the root LICENSE, third-party notices, and module paths. The push archive also contains its declared ak-permissions dependency. Temporary private-workspace changes do not enter this packaging step.
Record the module name, version, commit, and local changes after adoption. Project-specific permission or configuration patches should remain inspectable so an upgrade does not overwrite them unnoticed. Inspect archive paths before extraction and compare existing modules before copying.
Read verification records precisely
| Record | What it establishes | What remains to check |
|---|---|---|
| Source and dependencies exist | Review and integration can begin | Toolchain and platform compatibility |
| A build passes locally | This toolchain generates an artifact | Signing, provider setup, and actual operation |
| An operation works on a device | The path works in that environment | Other target systems and failure cases |
| Versions and patches are recorded | Upgrade differences can be compared | Business regression after the upgrade |
The catalog provides inspectable source. The adopting project records its device results. Keep provider-dependent behavior unverified when credentials are missing; a local mock establishes only simulated behavior.
These modules integrate during the app build. Downloading them from the website does not install or execute code on the server. The catalog links to pinned source and module READMEs. To prepare your own reusable module, use the source-release workflow.