For years, our warning system for Apple and Google changes was a developer whose build failed first. The community gave us excellent reports, but the sequence was backwards. A platform owner announced a deadline, time passed, an application hit the change, and only then did we trace it into the builder.
What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.
This week we started a daily scheduled Codex task that reads official notices and checks them against Codename One. Its first useful results include Android 16 back handling in PR #5673 and the permission-safe Contact Picker in PR #5680.
For the rest of the release, read the weekly overview. The Contact Picker has a separate code-focused article.
A notice is the start of an investigation
Scheduled browsing alone would create noise. Platform pages change wording, policies overlap, and a requirement may already be handled in a builder branch that application code never sees. The task must connect the notice to an artifact we produce.
We require a primary source, an applicability test, and a concrete Codename One producer before filing work. A release-note headline is not enough. For native libraries, a Gradle setting is not enough either; the packaged binary may need inspection.
The scheduled task does not merge code or declare support from a search result. It narrows the distance between a platform announcement and an evidence-backed change.
Android 16 changed the Back contract
Applications targeting Android 16 no longer receive the old onBackPressed() path in the situations Codename One depended on. Without a registered predictive-back callback, Back could leave the application instead of navigating its form stack.
Google's target API requirements moved application updates to Android 16. The fix registers an OnBackInvokedCallback bridge and routes it into the existing Codename One back command. The Android builder still compiles against an older SDK surface in parts of the pipeline, so the bridge uses reflection and a proxy rather than linking the newer class directly.
System Back gesture
|
OnBackInvokedCallback
|
PredictiveBackBridge
|
Codename One back command
Input methods can emit both a legacy key event and the new callback. The bridge suppresses the duplicate so one gesture does not navigate twice. Predictive progress animation is not part of this change; correctness came first.
This is exactly the kind of regression that can hide until a target-SDK deadline changes which platform path is active. The daily scan connected the policy date to the generated Android activity and its runtime behavior.
Contact policy became an API design task
Google's contacts permission policy is not solved by changing one manifest line. Many applications ask for an address-book permission only to let the user choose one person. The appropriate response is a narrower interaction, not a more elaborate permission dialog.
That led to ContactPicker, which uses the Android system picker on Android 17, a permission-free single-contact fallback on older Android versions, and CNContactPickerViewController on iOS. The picker returns the selected snapshot. It does not grant the application a standing right to query the address book.
The next article covers requested fields, multi-selection limits, snapshots, fallbacks, and builder permission detection.
What this changes for release work
The immediate changes matter. The larger gain is a repeatable process:
- Read Apple and Google primary sources every day.
- Extract a date, affected target, and technical condition.
- Search issues and merged code before creating work.
- Trace the actual producer, including build-server generators and packaged artifacts.
- Reproduce the gap or prove the current output already satisfies it.
- Patch and test the narrow affected path.
The developer guide overhaul in this release follows the same idea. Structure, cross-references, missing code listings, links, images, and prose now have CI gates. A problem found by automation becomes a specific repair instead of a vague promise to keep the docs current.
Ahead of the deadline, with evidence
Automation will miss notices, misread scope, and find changes that do not apply. That is why the result is a source trail rather than an autonomous verdict. We can inspect the notice, the relevant builder, the generated product, the tests, and the merged fix.
Calls, VPN, OTP, contacts, billing, and platform navigation all sit near permissions or operating-system policy. Finding changes earlier gives us time to choose the narrower API instead of making a deadline patch that widens access. It also moves security work into the normal release cycle, where it can be reviewed beside the code it protects.
The next article shows how to pick one contact without asking for the address book.
