Add com.codename1.security: biometric auth + secure storage#4987
Merged
Conversation
Promotes biometric authentication (Touch ID, Face ID, Android BiometricPrompt) from the FingerprintScanner cn1lib into core so it is available alongside Location, Capture, and the other first-class device APIs. Public surface mirrors Flutter's local_auth: typed BiometricType list, typed BiometricError codes, AuthenticationOptions builder, and a stopAuthentication() cancel. iOS port wraps LocalAuthentication.framework + Security.framework (SecItemAdd / SecItemCopyMatching / SecItemDelete). Android port keeps the cn1lib's dual path -- FingerprintManager on API 23-28 and BiometricPrompt on API 29+; the BiometricPrompt + BiometricManager calls go through a reflection adapter (BiometricsApi29) because the cn1-binaries android.jar predates API 28. JavaSE port adds a Simulate -> Biometric Simulation submenu (Available toggle, per-modality enrollment, configurable next-call outcome) so apps can be exercised in the simulator. The Maven plugin always links LocalAuthentication.framework on iOS and injects USE_BIOMETRIC / USE_FINGERPRINT permissions on Android so apps don't need build hint surgery. The existing FingerprintScanner cn1lib continues to work unchanged for projects that depend on it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Collaborator
Author
|
Compared 20 screenshots: 20 matched. |
Collaborator
Author
|
Compared 11 screenshots: 11 matched. |
Collaborator
Author
|
Compared 110 screenshots: 110 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
CI surfaced two issues against the initial commit:
1. CodenameOne/ and Ports/CLDC11/ run a validator that rejects classic /**
Javadoc -- the codebase has standardised on /// markdown comments. Convert
all 8 files in com.codename1.security to that style and translate
{@link X} / {@code Y} to [X] / `Y` markdown.
2. IOSNative.m calls com_codename1_impl_ios_IOSBiometrics_* and
com_codename1_impl_ios_IOSSecureStorage_* callbacks but did not #include
the ParparVM-generated headers, so clang complained about implicit
function declarations and the iOS native build, build-ios, build-ios-metal
and packaging jobs all failed identically. Add the two #includes alongside
the existing com_codename1_impl_ios_IOSImplementation.h include.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
JDK 17 (and JDK 8) javac on CI defaults file.encoding to US-ASCII;
file.encoding=UTF-8 is only the JDK 18+ default per JEP 400. That made
the em-dash in AndroidBiometrics.java:64 ('-- values are stable per
AOSP') fatal with three "unmappable character" errors and broke the
Ant compile step. Replace with ASCII double-hyphen to match the
ASCII-only invariant documented in CLAUDE memory.
Also remove the unreachable UnrecoverableEntryException catch in
AndroidSecureStorage.getSecretKey -- keyStore.getKey() only declares
UnrecoverableKeyException, not its parent, so the second clause is
dead code (javac warning) and the import is unused.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
build-test (8) flagged LI_LAZY_INIT_STATIC on the lazy `fallback` field in both Biometrics.getInstance() and SecureStorage.getInstance() -- the if-null-then-assign-then-return pattern isn't thread-safe and the workflow treats this rule as forbidden. The fallback stubs are cheap immutable objects, so promote them to `private static final` eager fields and return them with a ternary. Also drop the explicit no-arg constructors on AuthenticationOptions, StubBiometrics and StubSecureStorage (PMD UnnecessaryConstructor) -- the compiler-generated default has the correct visibility in each case (public, package-private, package-private). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 110 screenshots: 110 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 110 screenshots: 110 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
…ject CodeQL alert "Insecure local authentication" (java/android/insecure- local-authentication, alert #108) correctly flagged that AndroidBiometrics.authenticate() granted access on the bare onAuthenticationSucceeded callback. Without a CryptoObject the success path can be reached via runtime hooking tools (Frida) without the user ever actually authenticating. Add a single-use AES probe key to the AndroidKeyStore with setUserAuthenticationRequired(true) and (API 24+) setInvalidatedByBiometricEnrollment(true), initialise a Cipher under it, and pass that Cipher to BiometricPrompt / FingerprintManager as the CryptoObject. The success callbacks then run authedCipher.doFinal(PROBE_PLAINTEXT); a real biometric unlocks the cipher and the doFinal returns, a spoofed callback fails because the Keystore refuses the operation. Probe key is recreated on KeyPermanentlyInvalidatedException (which happens when the user enrols a new biometric -- the security property CodeQL is asking us to enforce). The key is independent of the AndroidSecureStorage per-account keys, so SecureStorage entries are not affected when the probe is rotated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tighten the legacy FingerprintManager success path so CodeQL's dataflow analyser can see unambiguously that the cipher used for doFinal() comes from the AuthenticationResult.getCryptoObject() that the OS returned, not the local probe Cipher variable. If the result is missing a CryptoObject (shouldn't happen, but a spoofed callback might supply null) we now fail with AUTHENTICATION_FAILED rather than falling back to the local cipher reference. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Round of fixes from the PR review: 1. **Non-abstract base classes.** Biometrics and SecureStorage are now concrete with no-op default implementations -- StubBiometrics and StubSecureStorage are deleted. The default class is returned as the fallback for unsupported ports, so app code never needs a null check or a platform if. Reduces class count and eliminates two public-package types that were really impl details. 2. **Six SIC_INNER_SHOULD_BE_STATIC_ANON warnings fixed** in AndroidBiometrics + AndroidSecureStorage by converting the self-contained Runnables / CipherWork lambdas to actual Java 8 lambdas (the Android port already compiles -source 1.8). 3. **SpotBugs forbidden_rules now applied across every project**, not only core-unittests. A regression in android/ios spotbugs now fails CI exactly the way a regression in core does. 4. **Conditional injection.** IPhoneBuilder and AndroidGradleBuilder only inject LocalAuthentication.framework / USE_BIOMETRIC / USE_FINGERPRINT when the bytecode scanner observes any com.codename1.security class. Apps that never touch the API pay nothing. Mirrored in BuildDaemon (legacy build server). 5. **JavaSEBiometrics installBuildHints** -- first time the API is touched in the simulator, set ios.NSFaceIDUsageDescription on the project (placeholder text the developer should overwrite). Mirrors the historical FingerprintScanner cn1lib pattern. 6. **/// javadoc on every public getter / setter / enum constant** under com.codename1.security; STRONG/WEAK/IRIS now explained; iOS/Android/JavaSE/fallback behaviour spelled out throughout. 7. **Developer guide chapter** docs/developer-guide/Biometric- Authentication.asciidoc covering quick start, platform support matrix, build hints, prompt configuration, typed errors, simulator workflow, and the Keystore-bound success-verification security note. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Developer Guide build artifacts are available for download from this workflow run:
Developer Guide quality checks: |
Contributor
Cloudflare Preview
|
build-test (8) runs the Android port Ant build with -source 1.6 (the
Maven build uses 1.8, so my local checks missed this). Revert the
Java-8 lambdas added in the previous commit to named private static
inner classes -- same SpotBugs SIC_INNER_SHOULD_BE_STATIC_ANON
outcome, Java 1.6 compatible.
Also clean up the new docs/developer-guide/Biometric-Authentication
asciidoc against the project's Vale style ruleset: 8 Microsoft.
Contractions findings (is not / will not / cannot / does not / was not
must be contractions), one Microsoft.Auto (don't hyphenate
"auto-sets"), one Microsoft.Adverbs ("silently" removed).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three editorial cleanups requested in PR review: 1. Drop the comparison to Flutter local_auth in Biometrics.java javadoc and in the developer guide intro. The API stands on its own. 2. Avoid asciidoc em-dashes (--) throughout the new chapter. Replace with colons in headings and definition lists, semicolons or full sentences in prose. The four-dash code-block delimiters (----) are intentional asciidoc syntax and remain. 3. Drop the "legacy build daemon" wording. The build daemon is the build server and is not legacy. Reword to "the Codename One Maven plugin and the build daemon both automatically inject ...". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous round of feedback flagged that the build-hint injection wasn't visible in JavaSEPort -- it was buried in JavaSEBiometrics' public methods. Move the logic to JavaSEPort.installBiometricsBuildHints IfNeeded() and call it from getBiometrics() and getSecureStorage(). The semantics are unchanged: the first time the application touches either API in the simulator we detect whether ios.NSFaceIDUsageDescription is set on the project; if not, write a placeholder so the next iOS device build doesn't crash. The developer should overwrite the placeholder text with their app-specific localised reason before shipping (Apple rejects builds with the placeholder default). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vale's Microsoft.HeadingColons rule flags lowercase first words after a heading colon. Capitalise "Authenticate" and "Secure storage" in the two Quick start subsection titles. Fallout from the em-dash removal in the previous commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The TeaVM cloud-build that ships the playground crashed mid-compile on the previous commit (RMI EOFException from the build daemon). The new com.codename1.security classes (Biometrics, SecureStorage and their helper types) are present in the core jar the playground depends on, and the generated CN1 reflection bridge in tools/GenerateCN1AccessRegistry attempts to expose them. The cloud TeaVM backend doesn't yet know how to handle the new bridge classes, so the daemon dies before the playground can finish building. Add the six new types to INTERNAL_CN1_TYPES (the same exclusion list that already carries Simd, Accessor and IOAccessor) so the registry generator skips them. This is a one-release workaround: once the backend cloud build server is updated and rolls a new plugin, the exclusions can be removed and biometrics will work inside playground scripts too. Apps built off the device-side builders are unaffected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
added a commit
that referenced
this pull request
May 21, 2026
Resolves conflicts with the parallel "com.codename1.security: biometric auth + secure storage" addition (#4987) that also landed in com.codename1.security. The two contributions are independent class sets that happen to share the package -- preserved both. Conflict resolution: - IOSNative.m: keep both the crypto bridge block (#ifdef CN1_INCLUDE_CRYPTO) and the biometrics + SecureStorage block back-to-back. - IPhoneBuilder.java: keep usesBiometrics + usesCryptoAPI/usesCryptoGcm fields side by side and route classes in com/codename1/security/ to the right flag by name (Biometric*, SecureStorage and AuthenticationOptions go to biometrics; everything else goes to crypto). - GenerateCN1AccessRegistry.java: extend the existing one-release INTERNAL_CN1_TYPES exclusion to cover the new crypto types too, so the playground bridge generator skips them until the cloud TeaVM backend catches up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
added a commit
that referenced
this pull request
May 21, 2026
CI's javac on JDK 8 / 17 / 21 uses the US-ASCII default file.encoding (file.encoding=UTF-8 is only the JDK 18+ default per JEP 400) and choked on the section-sign character in two new doc comments: RFC 4648 §5 Swap the symbol for the spelled-out "sec" abbreviation, mirroring the ASCII-only convention noted in the previous biometrics commit (#4987) that fixed the same family of failures for the em-dash. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
added a commit
that referenced
this pull request
May 21, 2026
* Add com.codename1.security crypto API + OtpField widget
Introduces a first-party cryptography API in com.codename1.security so apps
no longer need an external cn1lib for routine hashing, MAC, encryption,
signing, JWT, and OTP work. Pure-Java algorithms produce identical output
on every platform; AES/RSA/Signature/SecureRandom route through each port's
native crypto provider.
New public API:
- Hash MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (pure Java)
- Hmac RFC 2104 + constant-time compare (pure Java)
- SecureRandom platform CSPRNG with bias-free intBelow/longBelow
- Cipher AES (GCM, CBC, ECB) and RSA (OAEP, PKCS#1)
- Signature RSA and ECDSA signing/verification
- KeyGenerator AES/HMAC keys, RSA key pairs
- Jwt JWT sign/verify for HS, RS, ES families (RFC 7519)
- Otp HOTP (RFC 4226) + TOTP (RFC 6238), authenticator-compatible
- Base32 / Base64Url, CryptoException
UI: com.codename1.components.OtpField -- segmented OTP input with
auto-advance, backspace stepping, paste distribution, and a complete
listener.
Impl layer:
- CodenameOneImplementation gains aesEncrypt/Decrypt, rsaEncrypt/Decrypt,
cryptoSign/Verify, secureRandomBytes, generateRsaKeyPair,
generateSymmetricKey. Default implementation uses java.security via
reflection so JavaSE simulator and Android work out of the box.
- com.codename1.io.Util exposes narrow public delegates the security
package uses; getImplementation() stays package-private.
iOS port:
- New Ports/iOSPort/nativeSources/CN1Crypto.{h,m} backs AES-CBC/GCM, RSA
OAEP/PKCS#1, RSA/ECDSA sign+verify, RSA keypair generation, and secure
random against Apple's Security framework + CommonCrypto.
- IOSNative + IOSImplementation override every crypto bridge method to
route through CN1Crypto.
Tests: 32 new tests under maven/core-unittests with RFC reference vectors
(FIPS 180-4 for hashes, RFC 4231 for HMAC, RFC 4226/6238 for OTP), plus
AES-GCM tamper detection, RSA OAEP round-trip, RSA sign/verify with
tampering, and a JWT RS256 round-trip.
Developer guide: new "Cryptographic primitives" section in
docs/developer-guide/security.asciidoc with examples for every entry
point, an algorithm-constant reference table, and recommended-key-size
guidance.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Gate iOS crypto bridge with CN1_INCLUDE_CRYPTO; set Info.plist exemption
Apps that don't reference com.codename1.security.* now have none of the
CommonCrypto / Security framework encryption symbols in their iOS binary
-- and in particular, the AES-GCM SPI symbols (CCCryptorGCMAddIV etc.)
stay completely out unless the app opts in.
CN1Crypto.h: declare placeholder #define toggles
CN1_INCLUDE_CRYPTO
CN1_INCLUDE_CRYPTO_GCM
(commented-out by default; flipped by IPhoneBuilder when relevant)
CN1Crypto.m / IOSNative.m crypto block:
- All implementations wrapped in #ifdef CN1_INCLUDE_CRYPTO. When the
define is absent we emit no-op stubs that always return
CN1_CRYPTO_E_UNSUPPORTED so the IOSImplementation overrides have
something to link against but no encryption symbols are referenced.
- The AES-GCM SPI externs and cn1_crypto_aes_gcm body are nested
inside a separate #ifdef CN1_INCLUDE_CRYPTO_GCM so even apps using
AES-CBC / RSA / signatures don't pull in the private GCM symbols
unless they ask for it.
IPhoneBuilder:
- Adds usesCryptoAPI / usesCryptoGcm flags. usesCryptoAPI is set by
scanClassesForPermissions when any class in com/codename1/security/
is referenced; usesCryptoGcm is opt-in via the ios.crypto.gcm
build hint (default false).
- Flips the CN1Crypto.h placeholders to the active defines when
needed.
- When the crypto API is used, injects
<key>ITSAppUsesNonExemptEncryption</key><false/> into Info.plist so
App Store Connect doesn't re-prompt on every upload. We always
route through Apple-provided crypto (and, for GCM opt-in, stable
SPI symbols backed by libcommonCrypto), which qualifies for the
EAR 740.17 standard-cryptography exemption.
- ios.appUsesNonExemptEncryption build hint overrides the default
-- pass "true" if the app links proprietary crypto on top of ours,
or "" to omit the key and answer in App Store Connect.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Move crypto bridge defaults out of core; fix CLDC11 + iOS compile
The previous default implementation used java.security via reflection
inside CodenameOneImplementation. The core compiles against the CLDC11
java.lang.Class stub (no getMethod / getConstructor) and the iOS port
goes through ParparVM (no java.lang.reflect.Method symbols), so the
reflection broke the Ant test-javase build, the iOS native compile,
and every transitively-failing job (build, build-ios, build-ios-metal,
native-ios, packaging, build-test 8/17/21).
Refactor:
- CodenameOneImplementation: crypto methods now throw a clear
"not supported on this platform" RuntimeException by default;
zero java.security / javax.crypto references in core.
- JavaSEPort: real implementations using direct java.security /
javax.crypto calls (full JDK is on the classpath at compile time
and at runtime in the simulator).
- AndroidImplementation: same direct-JCE overrides; Android ships
the standard JCE provider.
- TestCodenameOneImplementation (unit-test fixture in core-unittests):
same overrides so the existing 32 crypto tests still exercise the
bridge end-to-end.
- iOS port already overrides via IOSNative + CN1Crypto.{h,m}; no
change there.
Also fixes vale-linter alerts on the new developer guide section:
- "and so on" -> rewritten without the suggestion
- "it is" -> "it's"
- "very deliberately" -> "have decided"
- "auto-advancing" -> "advances to the next box"
32/32 tests pass on the JavaSE bridge (Hash, Hmac, OtpField, Jwt,
Cipher, Signature, KeyGenerator, SecureRandom round-trips).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Satisfy PMD quickstart ruleset on new com.codename1.security code
CI's static-analysis quality gate fails the build on a set of forbidden
PMD rules. Bring the new package into compliance:
- ControlStatementBraces: add { ... } around single-statement if / else
/ for / while bodies that the previous draft wrote inline.
- MissingOverride: annotate every method that overrides one of
MessageDigestImpl's abstract / virtual hooks (reset, digest,
digestLength, update, processBlock, writeStateBigEndian) and the
Block64 base-class update overrides. Also annotate the
DataChangedListener.dataChanged inner class in OtpField.
- LiteralsFirstInComparisons: flip s.equals("X") -> "X".equals(s) in
MessageDigestImpl.create and Hmac.blockSizeFor.
- EmptyControlStatement: drop the empty if-truncated branch in
Sha512Family.digest; collapse to a single !truncated check.
- ForLoopCanBeForeach: convert the array index-loops to enhanced for
in Hash.toHex, Base32.encode and OtpField.fireCompleteIfFull.
- OneDeclarationPerLine: split chained int/long h0,h1,h2,...
declarations in the SHA inner classes onto separate lines.
- ClassNamingConventions: rename inner classes Sha2_32 -> Sha256Family
and Sha2_64 -> Sha512Family (the underscore violated the rule).
Local pmd:check on the new files now reports 0 violations from this PR.
Also pulls in the vale-asciidoc fixes for security.asciidoc that the
previous commit dropped (and that the build-docs job had already
flagged before this).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Satisfy Checkstyle on new com.codename1.security code
A second CI gate -- Checkstyle, also bound to the verify phase of
core-unittests -- flagged 109 brace-placement, whitespace, and
continuation-indent issues across the new files. Bring them to zero:
- LeftCurlyCheck (94 instances): split single-line `if (x) { y; }` and
single-line method definitions like
`public byte[] md5(byte[] d) { return create(MD5).digest(d); }`
into the canonical three-line form. Codenames One's checkstyle
config requires a newline immediately after the opening brace.
- WhitespaceAfterCheck (15 instances): add spaces after commas in
Hash.HEX array literal and after primitive `(long)` casts in
SecureRandom.longBelow.
- IndentationCheck (16 instances): bump SHA-512 word-mixing
continuation lines from 23 to 24 columns to match the
expected level (the `^` operator was one column shy of the
canonical four-space continuation).
Local mvn checkstyle:check + pmd:check both report 0 violations from
this PR after these changes; 32/32 security tests still pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* crypto API review feedback: reuse Base64, abstract Key, OTP tutorial, device test
Code-review feedback on PR #4994:
1. Reuse the existing util.Base64 instead of adding a parallel Base64Url
class. util.Base64 is already SIMD-optimized; layer URL-safe encode/decode
on top of its encodeNoNewline path and inherit the speedup.
- util.Base64: new encodeUrlSafe(byte[]) / decodeUrlSafe(String) that
run through the same fast encoder, then map +-> / -> _ and strip
trailing = padding (RFC 4648 sec5).
- Jwt, JwtTest, OtpTest, package-info: switch to the new helpers.
- Drop security/Base64Url.java entirely.
2. Pull the common key fields (algorithm, encoded, format) into a new
abstract Key base class. PublicKey/PrivateKey/SecretKey now extend it
and only carry the type-specific extras (static factories for the
asymmetric pair; getBitLength on the symmetric one).
3. Otp.otpauthUri(issuer, accountName, secret, ...): builds the canonical
otpauth://totp/... URI per the Google Authenticator KeyUri spec so the
secret can be displayed as a QR code on enrolment screens. Six-digit /
30-second / SHA-1 default matches what every authenticator app expects.
4. Developer guide: expand the OTP section into a real two-factor-auth
tutorial -- enrolment via otpauthUri + QR rendering, verification via
OtpField + Otp.verifyTotp, server-side guidance, rate-limiting note.
Documents three approaches for actually rendering the QR (server-side
render URL, QR cn1lib, plain Base32 typed entry) since core doesn't
ship a QR encoder yet.
5. CryptoApiTest: device-side coverage in scripts/hellocodenameone that
mirrors the JUnit assertions (hash + HMAC RFC vectors, HOTP/TOTP RFC
vectors, AES-GCM round-trip + tamper detection, RSA-OAEP round-trip,
RSA-SHA-256 sign/verify, JWT HS256 + RS256 round-trips, otpauthUri
shape). Registered in Cn1ssDeviceRunner; skipped on HTML5 (no crypto
bridge on the JS port yet).
SIMD acceleration for hashing was investigated but declined: SHA-2's
round state machine has data dependencies that block single-message
vectorization, and the current Simd surface doesn't expose 32/64-bit
rotation. The natural SIMD beneficiary in this PR -- Base64 -- is
already covered by util.Base64.
Local: pmd:check, checkstyle:check both 0 violations; 34 JUnit tests
pass (32 from prior commits + 2 new otpauthUri tests).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Strip non-ASCII section sign from Base64 URL-safe docs
CI's javac on JDK 8 / 17 / 21 uses the US-ASCII default file.encoding
(file.encoding=UTF-8 is only the JDK 18+ default per JEP 400) and
choked on the section-sign character in two new doc comments:
RFC 4648 §5
Swap the symbol for the spelled-out "sec" abbreviation, mirroring the
ASCII-only convention noted in the previous biometrics commit
(#4987) that fixed the same family of failures for the em-dash.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* iOS: emit ParparVM _R_int wrappers for the new crypto natives
The crypto bridge methods on IOSNative -- aesCbc, aesGcm, rsaEncrypt,
rsaDecrypt, sign, verify, generateRsaKeyPair -- all return an int.
ParparVM emits two C entry points for every non-void native: the
unmangled implementation (com_..._methodName___paramTypes) and a
_R_<returnType>-suffixed forwarder that the bytecode dispatcher
actually calls.
The earlier commits provided only the first half, so the previous
build-ios job (which transpiled the framework but didn't transitively
include the crypto code path) passed -- the symbols were dead-code-
eliminated. Adding CryptoApiTest to scripts/hellocodenameone now keeps
those methods alive, the linker hunts for the _R_int wrappers, and
the iOS packaging job fails with:
Undefined symbols for architecture arm64:
"_com_codename1_impl_ios_IOSNative_aesCbc___..._R_int"
"_com_codename1_impl_ios_IOSNative_aesGcm___..._R_int"
...
Forward each wrapper to the matching base implementation. The base
itself is either the real CommonCrypto-backed version (when
CN1_INCLUDE_CRYPTO is defined by IPhoneBuilder) or the
CN1_CRYPTO_E_UNSUPPORTED stub, so this single set of wrappers serves
both build configurations.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
com.codename1.security, so Touch ID / Face ID / Android BiometricPrompt are first-class APIs alongsideDisplay.capturePhoto,LocationManager, etc.local_auth: typedBiometricTypelist (FINGERPRINT, FACE, IRIS, STRONG, WEAK), typedBiometricErrorcodes (NOT_AVAILABLE, NOT_ENROLLED, LOCKED_OUT, PERMANENTLY_LOCKED_OUT, USER_CANCELED, KEY_REVOKED, ...), fluentAuthenticationOptionsbuilder, and a workingstopAuthentication()cancel.SecureStoragesibling API gives biometric-gated keychain storage (iOS Security framework, Android AES/AndroidKeyStore with the cn1lib's hard-won workarounds for Samsung 8.0.0 and the API 33 carve-out preserved).LocalAuthentication.frameworkon iOS andUSE_BIOMETRIC/USE_FINGERPRINTpermissions on Android, so apps don't need build-hint surgery.API
Port implementations
IOSBiometrics+IOSSecureStorage): wrapsLAContext.evaluatePolicy(...)andSecItemAdd/SecItemCopyMatching/SecItemDelete. 9 new natives added toIOSNative.java/IOSNative.m. Non-ARC-safe (matches the iOS port'sCLANG_ENABLE_OBJC_ARC=NOconfig).stopAuthentication()calls[LAContext invalidate]and resolves the in-flightAsyncResourcewithUSER_CANCELED— the cn1lib previously logged "not implemented on iOS" here.AndroidBiometrics+AndroidSecureStorage): keeps the cn1lib's dual path —FingerprintManageron API 23-28,BiometricPrompton API 29+. The API 29+ paths go through a small reflection adapter (BiometricsApi29) because the cn1-binariesandroid.jarpredates API 28; runtime resolution works fine on devices that support it. Preserves the cn1lib's non-obvious workarounds (Samsung 8.0.0 cipher-init quirk,setUserAuthenticationRequiredAPI 33 carve-out per FingerprintScanner Simulator - native j2me theme is not taken from project #8).JavaSEBiometrics+JavaSESecureStorage): adds aSimulate -> Biometric Simulationsubmenu next to the existingLocation SimulationandPush Simulation. Lets the developer toggle hardware availability, per-modality enrollment (Face / Touch / Iris), and the outcome of the nextauthenticate()call. State persists across simulator restarts viajava.util.prefs. Secure-storage round-trip works againstPreferencesso apps can be exercised end-to-end without a device.Test plan
-source 1.5 -target 1.5(mvn -pl core install -Plocal-dev-javase -DskipTests)JavaSEBiometrics/JavaSESecureStoragecodenameone-maven-pluginbuilds with the auto-injection edits toIPhoneBuilderandAndroidGradleBuilderBiometricType,BiometricError,AuthenticationOptions,BiometricExceptionagainst the built core jarSimulate -> Biometric Simulation -> Hardware Available+Face ID Enrolled, verifyBiometrics.getAvailableBiometrics()returns[FACE]and that cycling the "Next outcome" radio produces the matching success/error in the test appBiometricError.LOCKED_OUTafter repeated failures and thatstopAuthentication()dismisses the prompt[LAContext invalidate]cancellation path and theSecureStorageround-tripSecureStorageinvalidation: write a value, enroll a new biometric, verify the nextget(...)fails withBiometricError.KEY_REVOKEDon both Android and iOSios.add_libsor any biometric build hint; confirm the generated Xcode project linksLocalAuthentication.frameworkand the generatedAndroidManifest.xmlcontains<uses-permission android:name="android.permission.USE_BIOMETRIC" />BiometricsAPI in the same module without symbol conflicts🤖 Generated with Claude Code