DEV Community: Shai Almog

App Intents: One Java Declaration for Siri, Spotlight, and Shortcuts

Shai Almog — Thu, 03 Sep 2026 17:05:38 +0000

@AppIntent can expose a public static Java method to Siri, Spotlight, and Shortcuts. The same declaration can also drive an Android launcher shortcut or an internal application command.

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.

PR #5559 adds com.codename1.intents and the build-time annotations behind that integration. The build generates only the native declarations each target supports.

For encrypted SQLite and the rest of this week's work, see the weekly release overview.

A handler is a public static method

An app intent can run in a process the system started only to answer it. There may be no application object and no visible form.

private static final Object WORKOUT_TOTAL_LOCK = new Object();

@AppIntent(value = "log_workout", title = "Log a workout",
        description = "Records a completed workout",
        phrases = {"Log a workout in ${applicationName}"},
        headless = true, timeoutSeconds = 5)
public static IntentResult logWorkout(
        @IntentParam(value = "kind", title = "What kind of workout?",
                options = {"run", "ride", "swim"}) String kind,
        @IntentParam(value = "minutes", title = "How many minutes?") int minutes) {
    int total;
    synchronized (WORKOUT_TOTAL_LOCK) {
        total = Preferences.get("totalMinutes", 0) + minutes;
        Preferences.set("totalMinutes", total);
    }
    return IntentResult.value(String.valueOf(total))
            .withDialog("Logged " + minutes + " minutes.");
}

The method is static because the build generates a direct call. Runtime annotation lookup is unavailable in translated iOS code, and dead-code elimination removes methods with no Java caller. A reflection-based dispatcher could compile successfully and disappear from the shipped application. Intent handlers can run concurrently, so the preference update protects its read-modify-write sequence.

The Maven plugin validates declarations and generates native metadata during the build. A malformed phrase, missing entity query, or invalid route fails the build instead of producing a shortcut that silently vanishes.

Intents and routes answer different questions

A route maps a URL to a screen. An intent accepts typed parameters, can ask the user to choose an entity, and returns a result. A route has no return channel.

They meet when the intent should open a screen. opensRoute passes bound parameters through the existing route table:

@AppIntent(value = "show_workout", title = "Show a workout",
        phrases = {"Show my ${workout} in ${applicationName}"},
        opensRoute = "/workouts/{workout}")
public static IntentResult showWorkout(
        @IntentParam(value = "workout", title = "Which workout?")
        Workout workout) {
    return IntentResult.ok();
}

@Route("/workouts/:id")
public static Form workoutForm(@RouteParam("id") String id) {
    return buildWorkoutForm(id);
}

The {workout} placeholder expands to the selected entity's stable ID before the router matches /workouts/:id. The screen keeps one address. A deep link and a system intent reach it through the same router.

Entities let the platform ask which object you meant

An entity parameter represents an application noun such as a workout, playlist, or invoice. The platform can search those entities and ask the user to choose before the handler runs.

@IntentEntity(value = "workout", title = "Workout", indexed = true)
public static class Workout {
    @EntityId
    public String getId() { return id; }

    @EntityTitle
    public String getName() { return name; }

    @EntityQuery(EntityQuery.Kind.BY_ID)
    public static Workout byId(String id) {
        return WorkoutStore.find(id);
    }

    @EntityQuery(EntityQuery.Kind.SEARCH)
    public static List<Workout> matching(String query) {
        return WorkoutStore.search(query);
    }
}

The BY_ID query is required because an entity crosses the native boundary as its identifier. The identifier must survive releases and data reordering. A list position or content hash can later resolve to the wrong object without producing an error.

Intents.index(...) publishes entities to device search. Remove them when the underlying content disappears, or stale results remain visible after the application data is gone.

Headless means no window

A headless handler can use Storage, Preferences, Database, networking, logging, surfaces publishing, and indexing. It cannot use Form, Dialog, the camera, capture, or anything else that needs a window.

Platform-dispatched handlers do not run on the event dispatch thread. A foreground handler that needs to update the UI must use Display.callSerially(...). Intents.invoke(...) is synchronous and runs on the calling thread, which makes it useful as an internal command layer but also means a long handler can freeze the UI if invoked from the event thread.

Each invocation has a deadline. Cancellation is cooperative through IntentContext.isCancelled(). Commit durable changes as the work proceeds because a result returned after the platform deadline can be discarded.

Android shortcuts are not Siri

Android has no equivalent to Siri's typed invocation contract and spoken result channel. The API does not label launcher shortcuts as voice parity.

Capability	iOS	Android
Declared intent	App Intent and App Shortcut	Launcher shortcut
Voice phrases	Siri	Not available
Entity disambiguation	System picker	Application picker
Device search	Core Spotlight	Long-lived launcher shortcuts
Donation	Learned suggestions	Dynamic shortcuts
Headless execution	Background application launch	Service without an activity

Branch on Intents.isVoiceInvocationSupported() before telling a user to speak to the application. areIntentsSupported() answers a broader question.

Intents.invoke(...) works on every port because it calls the generated Java dispatcher. A desktop or web application can use the same intent as an internal command even when the operating system provides no external intent surface.

Widget actions use the separate surfaces API. A tap arrives through Surfaces.setActionHandler(...); that handler can call Intents.invoke(...) when a widget should reuse an intent. Declaring @AppIntent alone does not generate a widget action.

System integrations stay out when unused

An application that never references com.codename1.intents gets no native intent plumbing, shortcut resources, frameworks, manifest entries, or deployment-target change.

Spotlight indexing and donation use older Objective-C APIs and do not raise the iOS deployment target. Declaring an @AppIntent generates the newer Swift declarations. ios.intents.appIntents=false keeps indexing and donation while suppressing those declarations. ios.intents.minDeploymentTarget lets the project choose whether an intent contributes a floor.

The simulator's Simulate > App Intents window lists the generated declarations, builds parameter forms, fills entity pickers from the real query methods, and invokes the same dispatch table used by the native ports.

A workout handler remains one piece of Java application logic. Siri can invoke it by voice, Spotlight can find its entities, Android can publish it as a shortcut, and the application can call it directly through Intents.invoke(). Each platform integration remains native to that platform.

Return to the parent post for the database, watch, web, smart-home, camera, and security work that shipped with it.

CodeScanner.scan(): Barcode Scanning Without Rebuilding the Camera Pipeline

Shai Almog — Wed, 02 Sep 2026 17:09:59 +0000

The new vision analyzers could read barcodes, faces, poses, text, documents, and segmentation masks. Scanning one QR code still meant opening a camera, configuring a session, listening for frames, converting each frame, feeding a pipeline, moving the result to the event thread, and restoring the previous form.

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.

The low-level layer remains necessary for custom camera products. It should not be a prerequisite for reading one code or counting faces.

PR #5575 adds the missing layers above the analyzers. For the other work that shipped this week, see the weekly release overview.

One call owns the scanner screen

CodeScanner.scan() opens a scanner form, runs the barcode analyzer, returns the first accepted code, and restores the form the application was showing:

if (!CodeScanner.isSupported()) {
    ToastBar.showErrorMessage("This device cannot scan codes");
    return;
}

CodeScanner.scan().ready(code -> {
    if (code == null) {
        return; // the user pressed back
    }
    urlField.setText(code.getValue());
}).except(error -> Log.e(error));

Cancellation is a null result. A camera or decoder failure reaches except(...). That maps the old scanner library's three callbacks onto one AsyncResource without treating the back button as an error.

CodeScannerOptions changes the screen text and restricts the accepted formats:

CodeScanner.scan(new CodeScannerOptions()
        .title("Boarding pass")
        .hint("Hold the pass flat inside the frame")
        .formats(BarcodeFormat.PDF417, BarcodeFormat.AZTEC))
    .ready(code -> {
        if (code != null) {
            checkIn(code.getValue());
        }
    });

Restricting formats prevents a nearby product barcode from completing a QR-only flow.

One component owns the live pipeline

VisionCameraView covers the case where the preview belongs inside an application form. It opens the camera when shown, keeps only the newest frame while analysis is busy, delivers results on the event dispatch thread, and releases the camera when the user leaves.

Form previous = Display.getInstance().getCurrent();
FaceDetector detector = new FaceDetector();
VisionCameraView<Face[]> view = new VisionCameraView<>(detector);
view.setFacing(CameraFacing.FRONT);
view.setListener(new VisionPipelineListener<Face[]>() {
    public void result(Face[] faces, VisionImage source) {
        countLabel.setText(faces.length + " face(s)");
    }

    public void error(Throwable error) {
        Log.e(error);
    }
});

Form form = new Form("Faces", new BorderLayout());
form.add(BorderLayout.CENTER, view);
form.add(BorderLayout.SOUTH, countLabel);
form.getToolbar().setBackCommand("Back", event -> {
    view.close();
    previous.showBack();
});
form.show();

The analyzer remains caller-constructed. That is how the build decides which native model to package. A face-detection application should not carry barcode, pose, and segmentation dependencies merely because a high-level component knows those analyzers exist.

Leaving the form temporarily stops the camera but keeps the analyzer ready in case the form is shown again. Call close() from the navigation path that discards the screen permanently. It releases both resources and cannot be reversed.

Results use types and component coordinates

Backend strings such as "QR_CODE" and "leftEye" are now represented by BarcodeFormat, FaceLandmarks, and PoseLandmarks. Geometry helpers turn normalized analyzer coordinates into pixels an application can draw.

Rectangle box = faces[0].getBounds()
        .toBounds(0, 0, photo.getWidth(), photo.getHeight());

Image face = photo.subImage(box.getX(), box.getY(),
        box.getWidth(), box.getHeight(), true);

VisionImage.fromFile(...) and VisionImage.fromImage(...) bridge picked images into the analyzer path. Encoded images keep their original bytes instead of being decoded and encoded again.

Selfie segmentation also gets the operation that makes its result immediately usable:

SelfieSegmenter segmenter = new SelfieSegmenter();
EncodedImage photo = EncodedImage.create(jpegBytes);

segmenter.process(VisionImage.encoded(jpegBytes)).ready(mask -> {
    Image person = mask.cutOut(photo, 0.6f);
    preview.setIcon(person);
    segmenter.close();
}).except(error -> {
    Log.e(error);
    segmenter.close();
});

Pixels below 60 percent foreground confidence become transparent.

High-level classes must still select native dependencies

The build scans application classes, not every class in core. An application referencing only CodeScanner never directly names BarcodeScanner. Without an explicit mapping, the build could prune the barcode adapter and camera natives while still compiling successfully.

The new high-level classes select the dependencies they need. HighLevelVisionDependencyTest walks the vision sources and fails when a future convenience class is added without a corresponding build mapping. This tests the failure mode that would otherwise appear only as an inert feature on a device.

Vision can be scripted before hardware arrives

In the simulator, Simulate > Vision can mark a feature supported or unsupported and select a result, no-result, backend-error, or unsupported outcome. Scripted results include plausible geometry.

That lets an application test cancellation, debounce behavior, overlays, and error copy without a camera or a trained model. It also makes the same application code run in desktop UI tests.

The preview remains a native view. iOS and Android do not give native peers the same stacking order, so portable components should sit around the preview rather than assume they can paint a reticle on top of it. Only one camera session can be open at a time. The non-default preview scale modes are currently honored by the simulator but ignored by the iOS and Android camera previews.

The low-level APIs remain available for products that need direct frame control. The change is that barcode scanning, face counting, and common camera analysis no longer start by rebuilding the plumbing.

The next post shows how to expose a Java intent to Siri, Spotlight, and Shortcuts.

Tapjacking Protection: Rejecting Android Touches Behind an Overlay

Shai Almog — Tue, 01 Sep 2026 17:19:37 +0000

We are continuing our security hardening work with protection for the input path. A confirmation screen can be correct and still receive a tap the user did not understand. On Android, another application can draw over the screen and make a transfer button look like part of a different interaction.

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.

PR #5553 adds tapjacking and screen-overlay protection to DeviceIntegrity. It can report the condition, drop the full gesture, and ask Android 12 or newer to prevent overlay windows on a sensitive screen.

The weekly release overview also covers encrypted SQLite, which protects stored bytes. Tapjacking protection controls input while the application is running.

Android reports the overlay on the touch

Android marks a MotionEvent as fully obscured when another window covers the point that was touched. It marks the event as partially obscured when another window covers any part of the application window.

Those signals have different false-positive rates. A fully obscured touch is the tapjacking case. Partial obscuring can come from ordinary system UI.

Detection is therefore touch-driven. isScreenObscured() describes the latest observed touch. It is not a live query for every window on the device. An overlay that appears while nobody touches the application produces no event to inspect.

Four policies make the cost explicit

TapjackingPolicy has four modes:

Policy	Reports	Drops fully obscured gestures	Drops partially obscured gestures
`OFF`	No	No	No
`REPORT`	Yes	No	No
`BLOCK`	Yes	Yes	No
`STRICT`	Yes	Yes	Yes

BLOCK is the normal setting for a sensitive application. REPORT is useful before enforcement when you need to measure what devices and installed tools produce. STRICT can discard intended taps caused by benign system UI, so it belongs only on flows where missing a tap is preferable to accepting a framed one.

The runtime setup can live in init():

DeviceIntegrity.setTapjackingProtection(TapjackingPolicy.BLOCK);

DeviceIntegrity.addTapjackingListener(event -> {
    if (Boolean.TRUE.equals(event.getSource())) {
        Dialog.show("Security warning",
                "Another app is drawing over this screen. "
                        + "Close it before continuing.",
                "OK", null);
    }
});

The listener receives state transitions rather than one callback per touch. Read the state from the event. The callback is delivered on the event dispatch thread, while a later clean touch can update the global state before a busy event thread handles the earlier warning.

A blocked gesture is all or nothing

Dropping only the press would let the matching release reach a component that never received a press. The port latches the decision from ACTION_DOWN through UP or CANCEL. Application components receive none of the gesture.

The Android port performs the check explicitly before the event reaches Codename One. The normal Android setFilterTouchesWhenObscured() path is not enough because the Codename One view dispatches directly into its own touch handler. The standard filter remains enabled on fallback paths as a second layer.

This also matters for native peers. A BrowserComponent or native text field can have a platform-specific event path. Preventing the overlay window is stronger than filtering touches after they arrive.

Android 12 can hide overlays

On a sensitive screen, combine the touch policy with overlay prevention and screen capture protection:

if (DeviceIntegrity.isHideOverlayWindowsSupported()) {
    DeviceIntegrity.setHideOverlayWindows(true);
}
DeviceIntegrity.setSecureScreen(true);

isHideOverlayWindowsSupported() requires Android 12 or newer and the android.permission.HIDE_OVERLAY_WINDOWS manifest permission. The zero-code guard adds the permission and chooses the normal policy:

android.tapjackingGuard=true
android.tapjackingGuard.mode=block
android.tapjackingGuard.hideOverlays=true

Clear setHideOverlayWindows(false) and setSecureScreen(false) when the application leaves the sensitive flow if the rest of the product allows those features.

iOS does not allow the same cross-application overlay

iOS does not let one application draw a window over another, so the policy has no iOS work to do. Screen recording and mirroring are different threats and use ios.disableScreenshots=true.

The simulator exposes Simulate > App Shield > Screen Overlay (Tapjacking). It drives the same listener and signal path as the Android port, which lets the warning, policy transitions, and analytics path run on the desktop. Real-device testing is still needed for partial-obscuring behavior because system UI differs by Android vendor.

Tapjacking is not reported as a standing device-compromise reason. An overlay is transient and can be benign. Folding it into isDeviceCompromised() would make a notification shade look like a rooted device. Instead it raises its own App Shield signal and remains available as a local input policy.

BLOCK handles the high-confidence case by default. STRICT remains an explicit choice because partially obscured touches can come from benign system UI. Unsupported platforms do not report protection they cannot provide.

The next post restores a short path for common camera and vision cases.

One Java API for HomeKit, Matter, and Google Home

Shai Almog — Mon, 31 Aug 2026 19:30:15 +0000

A light can expose brightness through a HomeKit characteristic or a Matter cluster. Application code should ask for brightness, not carry both platform identifiers and two sets of value rules.

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.

PR #5554 adds com.codename1.home, a portable model for listing accessories, reading and writing traits, watching changes, running scenes, and commissioning Matter devices.

The API also reports cases where the platforms cannot give the same answer. For the other work that shipped this week, see the weekly release overview.

Traits describe the device, not the platform

A HomeStructure contains rooms and accessories. Each accessory contains services, and each service exposes traits such as ON_OFF, BRIGHTNESS, or TARGET_TEMPERATURE.

The port owns conversions that are easy to get wrong. Matter brightness uses a 0 to 254 level. Covering position runs in the opposite direction on some backends. Matter has no single thermostat setpoint in automatic mode. Air quality has a different number of levels in HomeKit and Matter.

TraitValue exposes the canonical value and retains the platform ordinal where a conversion loses detail. Proportional values become percentages. Temperature getters require the expected unit, preventing a Celsius value from being read as Fahrenheit by accident.

Availability has more than two states

SmartHome.getInstance() never returns null. Unsupported ports return a fallback that reports NOT_SUPPORTED. Supported ports use more specific states so an empty accessory graph is not mistaken for a configured home with no devices.

SmartHome home = SmartHome.getInstance();
home.refresh().onResult((structures, error) -> {
    HomeAvailability availability = home.getAvailability();

    if (availability == HomeAvailability.PROVIDER_NOT_INSTALLED
            || availability == HomeAvailability.PROVIDER_UPDATE_REQUIRED) {
        home.openProviderSetup();
        return;
    }
    if (availability == HomeAvailability.PERMISSION_REQUIRED) {
        home.requestAuthorization();
        return;
    }
    if (availability == HomeAvailability.PERMISSION_DENIED) {
        home.openHomeSettings();
        return;
    }
    if (availability == HomeAvailability.NOT_CONFIGURED) {
        home.openEcosystemApp();
        return;
    }
    if (error != null) {
        Log.e(error);
        return;
    }
    if (availability == HomeAvailability.COMMISSIONING_ONLY) {
        showAddDeviceOnlyUI();
    }
});

Read availability from the completion path even when refresh() fails. On iOS, the initial value is NOT_STARTED because connecting to HomeKit is what reveals the authorization and home state.

COMMISSIONING_ONLY is the normal Android result without Google Home developer setup. Play services can add a Matter accessory to the user's Google Home. Reading or controlling the accessory graph requires Google Home APIs, a Google Cloud project, and a Home Developer Console registration containing the application's signing-key SHA-1. Codename One cannot create those credentials for an application.

The Google Home accessory graph is not part of this release. Reporting full availability would make the same enum value mean different things on Android and iOS.

Reads and writes can partly succeed

A batch read returns one TraitReading per requested value. A reading can contain a value, contain an error, or contain neither. The third state is valid when a sensor has not measured yet or a light in white mode has no meaningful hue.

A batch write follows the same rule. Turning off every light can succeed for three accessories and fail for one unreachable bulb. The result carries each row instead of collapsing the operation into one boolean.

TraitReadRequest request = new TraitReadRequest()
        .add(thermostat, thermostatService, Trait.CURRENT_TEMPERATURE)
        .add(thermostat, thermostatService, Trait.CURRENT_HUMIDITY);

home.read(request).onResult((readings, error) -> {
        if (error != null) {
            Log.e(error);
            return;
        }
        for (TraitReading reading : readings) {
            if (reading.isFailed()) {
                showUnavailable(reading.getTrait());
            } else if (!reading.hasValue()) {
                showNoReadingYet(reading.getTrait());
            } else {
                show(reading.getTrait(), reading.getValue());
            }
        }
    });

Build controls from each service's TraitConstraint. A dimmer with a ten-percent floor reports that floor. Writing below it is refused rather than silently clamped.

Changes are state updates, not an event log

HomeKit can push trait changes while the application is in the foreground. Other backends require polling. TraitSubscription.isPushDelivery() tells the application which model it received.

Where push delivery is unavailable, call drainChanges() when the application returns to the foreground. Changes are coalesced by accessory, service, and trait. Dragging a dimmer can therefore produce one update with the final value instead of forty intermediate events.

Nothing in this release wakes a stopped application for an accessory change. The home hub owns background automation. The phone application owns a foreground view of current state.

Commissioning uses the operating system's setup flow

Both mobile ports hand Matter commissioning to a system-owned flow. The user may need to power on the accessory, hold a physical button, scan a label, and join Wi-Fi. The application receives no determinate progress to display.

SmartHome home = SmartHome.getInstance();
Commissioner commissioner = home.getCommissioner();
SetupPayload payload = SetupPayload.parse(scannedCode);

commissioner.commission(new CommissioningRequest()
        .setSetupPayload(payload)
        .setSuggestedName("Kettle"))
    .onResult((result, error) -> {
        if (error != null) {
            Log.e(error);
            return;
        }
        if (home.getAvailability() == HomeAvailability.COMMISSIONING_ONLY) {
            showAddedToHome(result.getAccessoryName());
            return;
        }

        home.refresh().onResult((structures, refreshError) -> {
            if (refreshError != null) {
                Log.e(refreshError);
                return;
            }
            showUpdatedHome(structures, result.getAccessoryId());
        });
    });

Success can mean the device joined the user's home without becoming addressable by the application. That is the normal result on an Android build with commissioning alone. On graph-capable builds, refresh after every successful flow. The default iOS Matter sheet does not return an accessory ID even though the new device appears in HomeKit, so the application must inspect the refreshed graph. wasCommissionedToThisApp() is useful when a backend returns a directly addressable ID, but it is not a substitute for that refresh.

The iOS build adds HomeKit entitlements only when application code touches accessories. Commissioning lives in its own package because it adds a generated app-extension target. An application that never references com.codename1.home gets no framework, entitlement, Play services dependency, or extension.

The simulated house contains the awkward cases

The simulator, desktop ports, and JavaScript expose a local house with a two-gang switch, bridged lights, an unreachable socket, a thermostat in automatic mode, and a dimmer with a nonzero floor.

Those cases make the application handle missing values, partial failures, constraints, and delayed callbacks before it meets real hardware. The simulator does not push changes and never completes an operation inline, which prevents desktop-only timing assumptions from becoming device bugs.

Automations, triggers, background events, topology writes, camera streams, alarm panels, and Matter events remain outside this release. By default Codename One also commissions through the Apple Home or Google Home ecosystem rather than becoming a Matter controller with its own fabric.

Application code can work with brightness, temperature, locks, and scenes without carrying HomeKit characteristic strings or Matter cluster IDs. Capability queries still expose the platform differences the product must handle.

The next post adds tapjacking protection to the security work.

JavaScript Find in Page: DOM Text Above the Codename One Canvas

Shai Almog — Sun, 30 Aug 2026 17:26:42 +0000

Browser search cannot find pixels. That was the JavaScript port's text model: Codename One drew each glyph onto a canvas, so a visible label was invisible to find-in-page, text selection, and ordinary browser text machinery.

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.

PR #5552 keeps the canvas renderer and promotes eligible visible text into a DOM layer. Codename One still measures and places every run. The browser handles the part it is better at: text rasterization, selection, search, accessibility, input metadata, and device-pixel resolution.

For encrypted SQLite and the rest of this week's work, see the weekly release overview.

A DOM component tree was the wrong trade

Replacing each Codename One component with a DOM element would hand layout and paint ordering to the browser. It would also create two UI implementations to keep consistent.

We kept application components on the canvas and projected only the text and accessibility data the browser needs:

The page now has a shape similar to this:

<canvas role="presentation" aria-hidden="true"></canvas>
<div id="cn1-text-layer" aria-hidden="true">
    <span style="position:absolute; white-space:pre">Account balance</span>
</div>
<div id="cn1-accessibility-tree" aria-label="Account balance"></div>

The text run arrives already broken and positioned. white-space: pre prevents the browser from wrapping it. Text measurement stays on the worker's OffscreenCanvas, so promoting a run does not alter layout.

Rebuilding the overlay broke the browser features

The accessibility projection previously cleared its container and recreated every element on each invalidation. Scrolling changes component bounds repeatedly, which meant scrolling also destroyed DOM focus and any active text selection.

The overlay now diffs the semantic tree. Stable nodes keep their element identity and listeners while their bounds or content change. The browser can maintain focus and selection because the application is no longer replacing the element under it.

The real-browser verification tags semantic elements with a JavaScript property, triggers invalidation, then reads the property again. Rebuilding the tree would lose the tag and fail the test. That makes incremental behavior part of the port contract rather than a performance assumption.

High-DPI displays use their native resolution

The old host code pinned devicePixelRatio to one. A 375 by 667 CSS box therefore had a 375 by 667 backing canvas even on a display with a pixel ratio of two. The browser enlarged that bitmap to the physical pixels.

The new path uses a 750 by 1334 backing surface behind the same 375 by 667 CSS box at a device-pixel ratio of two. Coordinates are converted at the DOM boundary, while Codename One continues to address device pixels internally.

CSS layout:      375 x 667
devicePixelRatio:        2
backing surface: 750 x 1334

The port also refreshes the ratio when browser zoom changes or a window moves between displays. Screenshot tests can still pin a specific ratio through the existing query parameter.

Inputs now tell the browser what they mean

Text editing already used a positioned native input. The new work fixes and extends the metadata the browser reads:

inputmode selects the appropriate on-screen keyboard.
autocomplete connects password managers and autofill.
autocapitalize and spellcheck follow the Codename One constraints.
The component name becomes the field name.
cn1$autocomplete can override the autocomplete token.

A password field bug also disappeared. PASSWORD is a bit flag, but the old code compared the entire constraint value. PASSWORD | EMAILADDR missed the password case and fell through to a clear-text input.

Several browser APIs had silently broken when the port moved into a worker. A @JSBody executes in that worker, so direct access to history, matchMedia, or other window-owned objects fails. Host bindings now restore browser history, dark-mode detection, reduced-motion and forced-color queries, and cursor support.

Some text stays on the canvas

The DOM layer is targeted. Text stays on the canvas when the DOM cannot reproduce the paint operation without changing its meaning:

Offscreen targets, transition buffers, ComponentImage, and screenshot rendering
Cell renderers whose single component instance is stamped at several positions
Text outside the displayed form when a dialog paints another form as its backdrop
Shape clips, transformed text, and bitmap fonts

Drag selection is also disabled for now. The text layer takes no pointer events so the canvas keeps owning hit testing. Find-in-page and keyboard selection work without that change. Mouse drag selection needs pointer routing that can distinguish text selection from component gestures.

Vertical placement can differ from browser font metrics by roughly one pixel. A sheet covering text inside the same form can also leave that text represented in the DOM until same-form occlusion is modeled.

Search works without handing layout to the browser

The JavaScript port still ships the Codename One UI. A browser cannot reflow a label, substitute a component, or change a layout after an OS update. The application owns those decisions.

The browser now sees enough structure to do what users expect from a web page. Search finds text. Assistive technology receives stable semantic nodes. Password managers recognize fields. High-DPI screens render at their actual pixel density.

The next post maps HomeKit, Matter, and Google Home without flattening their differences.

Watch Apps: One Codebase, Two Real Applications

Shai Almog — Sat, 29 Aug 2026 17:06:28 +0000

A watch app is not a second form in the phone process. It is another application on another device, with its own storage, startup sequence, and periods when the other side is unreachable.

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.

PR #5487 now builds an Apple Watch companion from codename1.watchMain. On Wear OS, the same entry point becomes the Android product when codename1.watchStandalone=true; a companion Wear APK beside the phone application is not generated yet. The release also adds one phone-to-watch API that maps to WCSession on Apple platforms and the Wearable Data Layer on Android.

For encrypted SQLite and the rest of this week's work, see the weekly release overview.

One entry point builds the watch application

The watch application starts from a fully qualified class name:

codename1.watchMain=com.example.MyWatchApp

# For a standalone Wear OS product:
codename1.watchStandalone=true

On Apple platforms, watchMain adds a companion target to the phone build. On Android, watchStandalone=true replaces the phone product with the Wear OS application rooted at watchMain. Without that flag, the Android build remains the phone application. The build logs that no companion Wear artifact was produced instead of quietly implying otherwise.

The Apple build derives the watch bundle identifier, deployment target, signing team, and display name from settings the project already has.

The phone and watch share source files, resources, CSS, and themes. They do not share runtime state. Each has its own Storage, Preferences, and SQLite files.

Wear OS reuses the Android port. watchOS uses a separate Core Graphics renderer because it has no UIKit view hierarchy, OpenGL ES, or Metal. The watch runtime sits inside a SwiftUI shell and runs its own ParparVM translation rooted at the watch entry point.

A message and a value solve different problems

The platforms offer several transports because a watch spends much of its life asleep.

Use putData() for state that should converge when the watch next wakes:

WearableConnection.putData(new WearableMessage("/steps")
        .put("count", stepCount)
        .put("goalReached", stepCount >= 10000));

Register the listener during init(). A payload can be the reason the platform started the process, so listeners attached from a later form may miss the replay window.

WearableConnection.addDataListener(new WearableDataListener() {
    public void dataChanged(WearableMessage data) {
        if ("/steps".equals(data.getPath())) {
            stepsLabel.setText("" + data.getInt("count", 0));
        }
    }

    public void dataRemoved(String path) {
        if ("/steps".equals(path)) {
            stepsLabel.setText("--");
        }
    }
});

Each data path holds the latest value. Two rapid writes can arrive as one update. That is correct for a step count and wrong for a queue of events.

Use sendMessage() when both applications must be awake and the sender needs an answer now:

WearableConnection.sendMessage(
        new WearableMessage("/workout/start"),
        new WearableReplyHandler() {
            public void replyReceived(WearableMessage reply) {
                showWorkout(reply.getString("id", null));
            }

            public void replyFailed(String message) {
                showReplicatedWorkoutState();
            }
        });

Failure is a normal branch. The phone may be asleep, out of range, or running an older version that does not know the message path. Do not use isReachable() as a preflight for a request with a fallback. Reachability can change after it is checked, and its first value during a cold start may still be unknown. Let replyFailed() select the replicated state instead. transferFile() covers files and large payloads that can arrive later.

The simulator runs two processes

The Watch > Launch Watch App command starts the watch beside the phone. The applications run in separate processes and connect through the desktop bridge, so sendMessage() and putData() take the same asynchronous route the application code expects on a device.

The simulator includes Apple Watch 41 mm and 45 mm skins, plus round and square Wear skins. Test the round skin even if the first target is Apple Watch. It catches layouts that depend on rectangular corners.

CN.isWatch() selects the form-factor-specific UI. The watch theme override changes styling without forking the rest of the theme:

Form form = new Form(BoxLayout.y());
if (CN.isWatch()) {
    form.add(new Label("Hi Watch"));
    form.getToolbar().setVisible(false);
} else {
    form.add(new SpanLabel("Welcome to the phone application"));
}
form.show();

Complications reuse the surfaces model

A complication is a small system-rendered surface driven by a timeline. That is the same model Codename One uses for widgets, Live Activities, and Dynamic Island content.

WidgetKind steps = new WidgetKind("steps")
        .setDisplayName("Steps")
        .addSupportedSize(WidgetSize.WATCH_CIRCULAR)
        .addSupportedSize(WidgetSize.WATCH_RECTANGULAR);

The watch sizes belong to WidgetSize instead of a second complication API. Application content can therefore share the same surface descriptors and timeline logic.

The system targets that render those watch families are not generated yet. watchOS still needs its WidgetKit extension target, and Wear OS still needs complication or tile services. The API establishes the common model without claiming those final platform adapters have shipped.

Android has one more current limit. Standalone Wear applications build today. A companion configuration does not yet produce a second Wear APK beside the phone APK. Apple Watch supports both companion and standalone targets, although standalone App Store submission still needs a manual archive step in Xcode.

Share code without pretending the watch is a phone

The watch and phone are separate products. They can still share application rules, visual assets, and surface descriptions. WearableConnection keeps the connection between them visible in ordinary Java code.

Write once, run anywhere does not require pretending every screen has the same lifecycle. A phone message can fail. A replicated value can arrive after a relaunch. A complication can render while neither application is active. The shared code handles those cases without hiding them.

The next post keeps the Codename One renderer while restoring browser-native text behavior.

SQLite Across Every Port: One Contract, One Encrypted File Format

Shai Almog — Fri, 28 Aug 2026 19:01:48 +0000

The original com.codename1.db implementation delegated SQLite calls to the database supplied by each operating system. We knew this was less portable than the rest of Codename One, but fixing it meant taking ownership of SQLite on every target. That looked like a deep rabbit hole, so we exposed escape hatches instead. The pluggable SpatiaLite work we described in 2018 is one example.

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.

On Windows and Linux, Database.openOrCreate() returned null. JavaScript depended on WebSQL, which Chrome removed and Firefox never implemented. An iOS cursor could report success on an empty result set, then read unset memory. The simulator counted rows from one while the other ports counted from zero. Encryption had no sensible place to live because there was no single database contract underneath it.

PR #5526 follows that rabbit hole to the end. It replaces the platform-dependent implementations with one specified and tested SQLite contract. It also resolves the long-standing encrypted database request. The same encrypted file can move between ports and open in a standard SQLCipher 4 client.

TL;DR

SQLite now has one tested contract, including native Windows and Linux implementations, SQLite compiled to WebAssembly for JavaScript, and encryption with three key models.
The watch apps deep dive treats the phone and watch as separate applications with separate lifecycles. WearableConnection gives them one asynchronous API for messages, replicated state, and files.
JavaScript text now appears as real DOM text above the canvas. Browser search, selection, accessibility, autofill, and native-resolution rendering work without handing layout to the browser.
Smart home support maps HomeKit, Matter, and Google Home concepts onto com.codename1.home, including a simulated house for desktop development.
Tapjacking protection detects and can reject Android gestures that begin behind another app's overlay.
Camera and vision regain the one-call ergonomics that were lost when the old scanner libraries were replaced by lower-level on-device analyzers.
App Intents expose a Java handler to Siri, Spotlight, Shortcuts, Android launcher shortcuts, and an internal command layer.

Each port had different SQLite behavior

The old API looked uniform because every port implemented the same Java methods. That said nothing about the result.

execute(sql) ran every statement on iOS, but silently stopped after the first statement in the simulator. getBlob() returned nil on iOS. The JavaScript cursor's position(n) always landed on row zero. The simulator leaked a prepared statement per query. ThreadSafeDatabase.close() returned before the close happened, so an immediate delete could race it.

These were not edge cases around a working abstraction. They meant a query tested in the simulator could have different transaction, cursor, or binding behavior on a device.

The new DatabaseConformanceSuite defines the contract once. Seven device tests exercise lifecycle, statements, cursors, transactions, encryption, and legacy behavior on every port-status target. The current reports show those tests passing on Android, both iOS renderers, JavaScript, native Linux, native Windows, macOS, tvOS, and watchOS.

Cursor navigation now derives from two primitives, rewind() and stepForward(), instead of being reimplemented on every port. Transactions return to autocommit after either commit or rollback. Blobs and typed parameters behave consistently. Windows and Linux finally open a database instead of returning null.

Fixing these inconsistencies changes behavior that some existing applications may rely on. A cursor index or transaction quirk can become part of application code even when the behavior was accidental. The db.legacy build hint keeps the previous implementations available during migration.

Older Ant projects default to legacy mode. They may be stable applications that only need another maintenance release, and forcing a database migration on them would be reckless. Newer Maven projects default to the corrected contract so new code does not inherit the old problems. Either project type can set db.legacy=true for the old behavior or db.legacy=false for the corrected contract.

DatabaseConfig opens the same encrypted format everywhere

Encryption is selected by passing a DatabaseConfig when the database opens:

if (Database.isEncryptionSupported()) {
    DatabaseConfig config = DatabaseConfig.managed();
    Database db = null;
    try {
        db = Database.openOrCreate("secure.db", config);
        // Read and write through db.
    } finally {
        config.wipe();
        if (db != null) {
            db.close();
        }
    }
}

There are three key models:

Key model	Where the key comes from	Good fit
`DatabaseConfig.passphrase(...)`	A secret supplied by the user or server	Data that must move to another device
`DatabaseConfig.managed()`	A random key stored in Android Keystore or the iOS keychain	Local data with nobody to prompt
`DatabaseConfig.rawKey(...)`	Thirty-two random bytes supplied by the application	A key managed by an existing backend or protocol

A passphrase compiled into the application is recoverable from the shipped binary. It is not a useful secret. A managed key avoids that mistake, but it also changes the recovery story: if the key-store entry is lost, the database is unreadable. Use a user-held or server-held passphrase when the data must survive a device loss.

Existing plaintext databases can be converted without replacing the API:

if (!Database.isEncrypted("customer.db")) {
    Database.encrypt("customer.db", DatabaseConfig.managed());
}

The on-disk parameters are fixed to the SQLCipher 4 format: AES-256-CBC, PBKDF2-HMAC-SHA512 with 256,000 iterations, 4,096-byte pages, and per-page HMAC-SHA512. CI writes a database with the Codename One engine and reads it with the stock sqlcipher client, then reverses the direction. That cross-engine test catches a class of failure where every port can read its own incompatible file.

Encryption protects data at rest. It does not protect an open database from a debugger, a memory dump, or code already running on a compromised device. That boundary is why this work sits beside App Shield and App Hardening instead of replacing either one.

JavaScript gets SQLite instead of a removed browser API

The JavaScript port used WebSQL because browsers once exposed it as a convenient SQL-shaped store. Chrome removed WebSQL in version 119. Firefox never shipped it. A portable API cannot depend on a feature that no longer exists in one browser and never existed in another.

JavaScript now runs SQLite compiled to WebAssembly and stores the database in the browser's storage pool. It passes the same statement, cursor, transaction, encryption, and compatibility tests as the native ports.

The new engine cannot read an old WebSQL store. openOrCreate() refuses to create an empty database when it detects that old data, because silently replacing a user's database with an empty state is worse than a visible migration. An application with WebSQL-era users must export from a build that can still read the old store, or deliberately opt into a new empty database with cn1.db.ignoreLegacyWebSql=true.

The build also remains pay-for-what-you-use. An application that never references com.codename1.db gets no database engine. A plain JavaScript database adds roughly 1.5 MB of WebAssembly. Referencing DatabaseConfig adds the cipher implementation where the platform needs it.

On Android, encryption raises the minimum SDK to 23 and requires AndroidX because those are SQLCipher's requirements. The unencrypted database path keeps the older floor.

That covers the database work. Six more changes shipped this week, each with its own detailed post.

The watch and phone now run as separate applications

A watch is not a small second window owned by the phone process. It has its own executable, storage, startup sequence, and failure modes. The watch applications post covers the complete model introduced by PR #5487.

One codename1.watchMain setting adds the Apple Watch companion entry point. On Android, codename1.watchStandalone=true builds that entry point as the Wear OS product instead of the phone application; a companion Wear artifact beside the phone APK is not generated yet. The simulator can launch the phone and watch as separate processes and connect them on the desktop. The pair shares source, resources, CSS, and the surfaces model. It does not share Storage, Preferences, or SQLite.

WearableConnection models the three transports the platforms actually provide. sendMessage() asks a live peer for an immediate reply. putData() replicates the latest state and survives sleep or relaunch. transferFile() moves a larger payload in the background. The API uses WCSession on Apple platforms and the Wearable Data Layer on Android.

WearableConnection.putData(new WearableMessage("/steps")
        .put("count", stepCount)
        .put("goalReached", stepCount >= 10000));

Complications join the existing surfaces vocabulary through watch-specific WidgetSize families. This reuses the same content and timeline model already used for widgets and Live Activities. The generated watchOS complication target and Wear OS complication service are not part of this release yet. Android also supports standalone Wear apps today, but does not yet generate a companion Wear artifact beside a phone APK.

Browser search now works in the JavaScript port

The JavaScript port has always rendered through a canvas. That gives Codename One control over layout and keeps the UI consistent, but it also turned visible text into pixels. Browser search could not find it. Users could not select it. The browser could not rasterize it at native resolution or expose it as ordinary text.

The JavaScript text post explains how PR #5552 keeps the canvas renderer and adds two targeted DOM layers above it. The text layer holds visible text runs at the positions Codename One already calculated. The accessibility layer holds the ARIA projection and updates it incrementally.

<canvas role="presentation" aria-hidden="true"></canvas>
<div id="cn1-text-layer" aria-hidden="true">Selectable, searchable text</div>
<div id="cn1-accessibility-tree" aria-label="..."></div>

The browser never gets to reflow a line or decide where a component belongs. It gets text that is already measured, broken, and positioned. Find-in-page, text selection, accessibility, native input metadata, password-manager hints, and high-DPI rendering can then use browser machinery without changing application layout.

Drag selection is still off because the text layer cannot take pointer events without changing canvas hit testing. Shape-clipped and transformed text stays on the canvas. Same-form occlusion, such as a sheet over text in the underlying form, also needs more work.

One API for HomeKit, Matter, and Google Home

The smart-home post introduces com.codename1.home from PR #5554, a common model for HomeKit, Matter, and Google Home. An accessory contains services. Services expose canonical traits such as ON_OFF, BRIGHTNESS, and TARGET_TEMPERATURE. Platform identifiers and unit conventions stay in the port.

That sounds like a normal abstraction until the platforms disagree. Matter and HomeKit express covering position in opposite directions. Matter has no single thermostat setpoint in automatic mode. Android can commission a Matter accessory into Google Home with little setup, but reading the accessory graph requires Google Home developer registration that Codename One cannot create for you.

The API reports that default Android state as COMMISSIONING_ONLY, not AVAILABLE. On iOS it can read and write HomeKit traits, run scenes, and commission Matter accessories. The simulator, desktop ports, and JavaScript run a deliberately awkward synthetic house so missing values, partial failures, and polling behavior can be tested without hardware.

Automations, background accessory events, camera streams, alarm panels, and the Google Home accessory graph on Android are outside this release. Each gap has a capability query or a specific availability state instead of turning into an empty list that looks like a real answer.

Tapjacking protection continues our security hardening work

We are continuing the push to make Codename One the secure default for application developers. The tapjacking protection post covers the input side of that work. Tapjacking happens when another Android application draws over a sensitive screen and changes what the user believes a tap will do. PR #5553 adds a TapjackingPolicy to DeviceIntegrity.

DeviceIntegrity.setTapjackingProtection(TapjackingPolicy.BLOCK);
DeviceIntegrity.addTapjackingListener(event -> {
    if (Boolean.TRUE.equals(event.getSource())) {
        showOverlayWarning();
    }
});

if (DeviceIntegrity.isHideOverlayWindowsSupported()) {
    DeviceIntegrity.setHideOverlayWindows(true);
}

REPORT observes without changing input. BLOCK drops a gesture that begins fully obscured. STRICT also drops partially obscured gestures, which can include ordinary system UI and therefore carries a real false-positive cost.

Detection is touch-driven because Android supplies the obscured state on MotionEvent. An overlay that appears without a touch is not detected by polling. On Android 12 and newer, setHideOverlayWindows(true) prevents overlay windows instead of reacting to their touches. iOS does not let one application draw over another, so the policy is an Android-only control rather than a fake cross-platform checkbox.

Scan a barcode without rebuilding the camera pipeline

The on-device vision work added barcode recognition, face and pose detection, text recognition, segmentation, document scanning, and image labeling. It also exposed every piece of the camera-to-analyzer pipeline. That was useful for custom camera products and needlessly low-level for common cases.

The camera and vision post covers the higher-level APIs in PR #5575. CodeScanner.scan() owns a complete scanner screen and returns one asynchronous result:

CodeScanner.scan().ready(code -> {
    if (code != null) {
        urlField.setText(code.getValue());
    }
}).except(error -> Log.e(error));

VisionCameraView packages the same pipeline as a component for a form you own. Typed BarcodeFormat, FaceLandmarks, and PoseLandmarks constants replace string literals. VisionRect.toBounds(...) and VisionPoint.toPoint(...) convert normalized analyzer geometry into component coordinates. SegmentationMask.cutOut(...) turns selfie segmentation into a usable image operation.

The preview remains a native peer. Components cannot be painted over it uniformly on every target, so controls and reticles should sit around it. One camera session can be open at a time. The simulator now scripts vision results, which lets the flow, overlay geometry, cancellation, and error paths run before the application reaches a device.

Expose an intent to Siri, Spotlight, and Shortcuts

The App Intents post shows how to expose a Java method to Siri, Spotlight, Shortcuts, or an Android launcher shortcut. PR #5559 puts the declaration in Java:

@AppIntent(value = "log_workout", title = "Log a workout",
        phrases = {"Log a workout in ${applicationName}"}, headless = true)
public static IntentResult logWorkout(
        @IntentParam("minutes") int minutes) {
    WorkoutStore.append(minutes);
    return IntentResult.spoken("Logged " + minutes + " minutes.");
}

The Maven plugin reads the compiled bytecode and generates a reflection-free dispatch table plus the native declarations. The direct static call matters on iOS, where runtime annotation lookup is unavailable and dead-code elimination can remove a handler that has no Java caller.

Entities let the platform ask the user which application object they meant. Intents.index(...) publishes those objects to device search. opensRoute connects an intent to the existing route table when the result should foreground a screen.

Android is not presented as Siri parity. It gets launcher shortcuts, donation, indexing, and headless execution. Voice invocation, system disambiguation, and spoken assistant results are iOS capabilities. Intents.invoke(...) still works on every port as an internal command layer, even when the operating system exposes no intent surface.

Security now covers storage, code, backend trust, and input

This week closes several gaps that used to be explained away as platform differences. SQLite now has one documented contract and one portable encrypted format. The watch and phone are separate applications with a defined channel. Smart-home traits and app intents project one application model onto native system services without pretending those services are identical. The web port keeps our renderer while restoring browser behavior users expect.

App Shield moves trust decisions to the backend. App Hardening raises the cost of reading and modifying the shipped binary. Encrypted SQLite protects stored data. Tapjacking protection rejects a class of misleading input on Android. None of these controls makes a compromised device trustworthy. Together they cover more of the path from stored bytes to the tap that authorizes an operation.

We want Codename One to lead cross-platform development on security. That requires more than adding isolated security switches. The safe path must be available from ordinary application code, included only when used, and tested on every target we claim to support. This week's encrypted database and tapjacking work move two more boundaries into that default path.

Start with the database guide if you have data at rest to migrate. Existing Ant applications should set db.legacy explicitly before moving to Maven. Applications with WebSQL-era browser data need an export plan before taking the new JavaScript engine.

App Hardening: One Obfuscation Pipeline Across Every Port

Shai Almog — Sat, 22 Aug 2026 13:30:18 +0000

Obfuscating only the Android artifact is a poor security model for a cross-platform application. Codename One App Hardening transforms the merged application before it splits into Android, iOS, JavaScript, Windows, Linux, and desktop builds.

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.

We set the target at DexGuard-class resistance: rename useful symbols, remove plaintext application strings where the target permits it, distort selected control flow, and keep crash reports readable. This is not a claim that reverse engineering becomes impossible. It is a commitment to make the same security decision cover the whole application instead of leaving every port to a different tool and configuration.

This post continues this week's release overview and GUI Builder rewrite and last week's App Shield release.

One transform before six platform builds

App Hardening runs on the merged application JAR inside the cloud build service. That placement matters. The engine sees application classes and bundled libraries before ParparVM translates bytecode to C, before R8 handles Android, and before the JavaScript or native desktop backends consume the program.

PR #5527 carries the open-source engine, retrace support, client API, build preflight, crash payload changes, and documentation. BuildDaemon PR #173 wires the engine into the cloud builders and enforces the Enterprise entitlement on the server.

The server gate is intentional. A non-Enterprise build that requests hardening fails with an explanation. It never returns an ordinary binary that looks protected because the client asked for protection.

Turn it on with one level

For most projects the only setting is:

codename1.arg.harden.level=standard

The levels are cumulative:

Level	Renaming	String encryption	Control flow
`off`	No	No	No
`standard`	Yes	Constant strings	No
`aggressive`	Yes	All eligible strings	One opaque-predicate guard
`paranoid`	Yes	All eligible strings	Two guards per eligible method

You can override the individual transforms with harden.rename, harden.strings, and harden.controlFlow. A per-platform harden.<platform>.enabled=false hint opts one target out. An unknown level fails the build instead of becoming off.

Classes resolved by name need a keep rule:

codename1.arg.harden.keep=-keep class com.example.payment.NativeGateway { *; }

The engine already keeps the application entry point, generated bootstraps, and native-interface peers. Codename One does not use runtime reflection to resolve ordinary application classes, which removes a large source of keep-rule guesswork. A third-party library that loads package-relative resources can still need an explicit rule because its package name changes while the resource path does not.

The port matrix is deliberately uneven

Applying every transform everywhere would produce a larger binary without adding protection, or break a backend optimizer. App Hardening uses one policy but adapts the mechanics:

Transform	Applied to	Why not everywhere
Class, method, and field renaming	iOS, JavaScript, Windows, Linux, JavaSE	Android keeps R8 as its only renamer to avoid chained renaming during the build.
String encryption	iOS, Android, Windows, Linux, JavaSE	JavaScript strings can be live references passed through the native bridge.
Control-flow obfuscation	Android and JavaSE	It conflicts with ParparVM optimization and inflates JavaScript output. Constructors are excluded.

The renaming dictionary uses a zq prefix rather than the familiar a, b, and c. Short names can appear inside ParparVM's generated native identifiers and confuse dead-code elimination. The longer prefix keeps the names opaque without disabling that optimizer.

A mapping looks like this in the retrace tests:

com.example.MyForm -> zqaaaa:
    10:10:void onSave():42:42 -> zqa
com.example.util.Helper -> zqaaab:

The mapping gets a build-specific ID and stays on the server for Crash Protection. Hardened stack traces carry that ID, the raw stack, trace format, and hardening level. The server retraces the report before filing the GitHub issue.

String encryption has sharp edges

Renaming hides labels. String encryption removes eligible application literals from the shipped binary and synthesizes a decoder inside each class with a per-class key. There is no single framework decoder for an attacker to hook.

The engine handles both ordinary LDC literals and static final String values stored in the class-file ConstantValue attribute. It also reports strings it cannot transform.

Three boundaries matter:

Annotation values remain in annotation metadata and stay readable.
JDK 9 style invokedynamic string-concatenation recipes can keep literal fragments outside ordinary LDC instructions. The build report counts those sites. Compiling with -XDstringConcat=inline moves them back into instructions the engine can transform.
An encrypted literal is value-equal to the same unencrypted framework string but may not be the same object. Compare strings with .equals(), not ==.

None of this turns a client-side constant into a secret. If the app can decrypt a value, an attacker controlling the process can eventually observe it. Credentials and signing secrets still belong on a server or in platform-backed secure storage.

Control flow is a cost, not a badge

Aggressive and paranoid levels add opaque predicates to eligible methods. A decompiler must keep branches that the application can resolve at runtime but static analysis cannot fold away.

The engine skips constructors and checks method growth before adding bytecode. It verifies the transformed classes with ASM's CheckClassAdapter before any platform builder sees them. The build report identifies methods or literals that were skipped instead of claiming a transform covered bytes it did not touch.

paranoid doubles the eligible control-flow guards. It also increases size and analysis complexity inside your own build. Start with standard, test a release build, then raise the level for code where the added cost has a reason.

Crash reports remain part of the contract

Obfuscation without retrace trades one security problem for an operational one. A production crash that says zqaaaa.zqa() does not help the team responsible for fixing it.

App Hardening and Crash Protection share the mapping lifecycle. Mapping upload is required by default. If upload fails, the build fails rather than ship an artifact whose future crashes cannot be decoded.

Application code can inspect the stamped result:

if (Hardening.isHardened()) {
    Log.p("Hardening level: " + Hardening.getLevel());
    Log.p("Mapping: " + Hardening.getMappingId());
}

The simulator and local source builds report false and off because they are never hardened. A local target fails preflight unless you explicitly set harden.allowUnhardenedLocalBuild=true. That escape hatch permits the build; it does not pretend to protect it.

Hardening, Shield, and encrypted data stop different attacks

Last week's App Shield release gives a backend a server-verified attestation token. Patching a local boolean is no longer enough to impersonate a trusted app when the server enforces that token.

App Hardening works earlier in the attack. It raises the cost of finding the code and constants an attacker wants to patch. App Shield makes a successful local patch insufficient for protected server calls. The open portable encrypted database PR adds the data-at-rest layer with interoperable encrypted SQLite files and keystore-managed keys. That database work is not merged yet, so it is direction rather than part of this release.

The security lead we are building comes from covering these boundaries together. Release builds already obfuscate by default. Enterprise teams can now add one cross-platform hardening policy, server-enforced attestation, Crash Protection retrace, and, once PR #5526 finishes review, portable database encryption. Each layer has a named failure mode and a testable output.

App Hardening still cannot stop a determined attacker who controls the device. It does not replace authorization, rate limits, secure key custody, or review of the operation your backend performs. It makes static analysis and casual tampering more expensive across every artifact you ship, which is the job an obfuscation layer can defend.

Start with standard, submit a release cloud build, and check the hardening report before moving to a stronger profile. The App Hardening guide documents every hint, exclusion, and local-build boundary.

The Third-Generation GUI Builder: One Workspace for Every Form

Shai Almog — Fri, 21 Aug 2026 13:39:34 +0000

We have rebuilt the Codename One GUI Builder again. This is its third generation. The interesting part is not another drag-and-drop surface. It is what we kept, what Maven broke, and why a visual editor must understand the whole project instead of opening one generated form at a time.

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 is a smaller rewrite than the second generation Steve Hannah built. His guided layout work remains the foundation. PR #5523 replaces the surrounding shell with a Maven-first Codename One application that moves between forms, CSS, and Java without leaving the workspace.

This week in one page

The third-generation GUI Builder is now a project workspace launched with mvn cn1:guibuilder.
App Hardening applies renaming, string encryption, and selected control-flow transforms before the platform builds split. The follow-up publishes Saturday.
The iOS on-device debugger no longer crashes when a reused local slot is mistaken for an object.
Port status and Linux video now report skipped tests instead of counting them as passes. The same work fixed three GStreamer defects.
Google Sign-In moved to version 7.1 so Apple Silicon simulators get a real arm64 simulator slice.
ParparVM memory reclamation now returns surplus BiBOP pages to the operating system after a small-object peak.
Missing and legacy URLs now lead to recovery pages instead of a bare 404.

Three builders, three different projects

The first GUI Builder grew out of tooling we built at Sun Microsystems. It stored forms inside the resource file and generated a central state machine. That model made sense when Codename One still targeted feature phones with roughly 2 MB of RAM.

The second generation separated a form into readable .gui XML and companion Java. Steve built auto layout on top of LayeredLayout, including smart insets, sibling references, matching sizes, baseline alignment, and multi-selection. It was a much better model for a modern application, but the editor still opened from a selected form.

That last assumption became painful after the Maven migration. A Maven project has forms under src/main/guibuilder, Java under src/main/java, and styling in src/main/css/theme.css. Launching a separate editor for every generated form turned navigation into the slow part of a visual tool.

The third generation changes the unit of work from a file to a project. It scans every .gui file, keeps them in the left panel, renders the selected form in the center, and shows its properties, layout, and events on the right.

One Maven goal opens the project

Create a form and open the editor from the project root:

mvn cn1:create-gui-form -DclassName=com.example.ProfileForm
mvn cn1:guibuilder -DclassName=com.example.ProfileForm

The first goal creates the pair that belongs in version control:

common/src/main/guibuilder/com/example/ProfileForm.gui
common/src/main/java/com/example/ProfileForm.java

The second goal resolves com.codenameone:codenameone-guibuilder through Maven and passes a project binding to the editor. IntelliJ IDEA, NetBeans, Eclipse, and Visual Studio Code now ship shortcuts that invoke the same goal. The editor itself remains a Java 8 artifact, so it runs on the JDK that already builds the application.

Switching forms no longer starts another process. The Forms tab is backed by a recursive scan of src/main/guibuilder, so a project with twenty forms behaves like a project with twenty forms, not twenty unrelated editor sessions.

Guided layout survived the rewrite

We did not replace Steve's layout model with absolute coordinates. A component dropped in auto layout mode still becomes a LayeredLayout child whose insets can refer to the parent or another named component.

Here is a trimmed form from the builder's demo project:

<component name="GuidedLayoutForm" type="Form" layout="LayeredLayout">
    <component name="heroTitle" type="Label"
        layeredinsets="24px auto auto 24px"
        text="Guided Layout" />
    <component name="description" type="SpanLabel"
        layeredinsets="12px 24px auto 0px"
        guidedreferences="heroTitle|-|-|heroTitle"
        guidedhorizontalsize="fill" />
    <component name="secondary" type="Button"
        guidedreferences="primary|primary|-|primary"
        guidedhorizontalsize="match"
        guidedmatchwidth="primary" />
</component>

Those names matter. A guide stored as an object pointer would disappear after a save and reload. A guide stored by component name survives on disk, which means the model must reject duplicate names and update references when you rename, delete, or paste a component.

The canvas adds the relationship while you drag. It can align edges, centers, and text baselines. Resizing can keep a preferred size, fill the parent, stay fixed, or match another component. The same canvas can switch from phone portrait to desktop width, which makes a bad relationship visible before it reaches a device.

The move above is not stored as a new set of absolute coordinates. It changes the relationship between primary and description, then lets LayeredLayout resolve the result for the current canvas.

CSS belongs beside the canvas

The second-generation builder and the old resource editor were separate tools. A user comment on our 2016 GUI Builder post asked for the editor to read the project CSS and render it directly. The third generation finally treats that as the normal workflow.

Click CSS and the project stylesheet opens beside the live form:

The pane edits the real src/main/css/theme.css. After the edit debounce, the CSS compiler installs the new theme and rebuilds the preview. A selector change is visible where it matters:

Button {
    background-color: white;
    color: #2459b8;
    border: 1px solid #315fce;
    border-radius: 2mm;
    padding: 2mm 4mm;
}

There is no second theme model to keep in sync. The stylesheet that colors the canvas is the stylesheet Maven compiles for the application.

Generated Java is visible, but not disposable

The Code button opens the companion Java source in the same workspace:

Generated code and user code have different ownership:

// <gui-builder-generated>
private Button signIn;

private void buildUI() {
    signIn = new Button("Sign in");
    signIn.setName("signIn");
    add(signIn);
}
// </gui-builder-generated>

// <gui-builder-user-code>
protected void onSignIn(ActionEvent event) {
    authenticate();
}
// </gui-builder-user-code>

The embedded editor protects the generated region instead of waiting for Save to overwrite it. Event handlers stay in the user region and survive regeneration. This removes an old timing problem where one IDE generated source on save while another waited for the next build.

The .gui file remains plain XML. You can review it in a pull request and recover it without a proprietary database. The current editor does not watch a hand-edited .gui file while it is open, so use Refresh after an external edit.

One hardening policy before the platform split

PR #5527 adds an open-source hardening engine that runs on the merged application before it becomes Android, iOS, JavaScript, Windows, Linux, or JavaSE output. The goal is DexGuard-class resistance without protecting one port and leaving the others exposed.

The policy is intentionally port-aware. Android keeps R8 as its sole renaming tool. JavaScript skips string encryption because its native bridge can hold live string references. ParparVM skips control-flow transforms that would fight its optimizer. The common pipeline still gives one build hint, one report, and a build-specific mapping connected to Crash Protection.

Saturday's App Hardening deep dive covers the exact port matrix, string-encryption exclusions, keep rules, retrace lifecycle, and local-build boundary. It also separates hardening from App Shield and the encrypted database work still under review.

A breakpoint no longer dereferences a random local

PR #5536 fixes the signal 11 crash that could take down an iOS app when NetBeans asked for locals at a breakpoint. One debugger table had one address per JVM slot but one row per declared local. Reusing a slot for an int and later an object could pair the object row with four bytes of integer storage, then dereference it as an eight-byte object pointer.

The generated table now stores one address per row. Frame entry clears stale debugger side channels, and object references pass through a Darwin memory-read check before native code dereferences them. The same PR adds real thread enumeration, deferred breakpoint replay, scoped locals, and ready-made on-device debug actions.

The PR added 66 tests around the generated C and JDWP proxy. It did not include a tethered-device debugging session, so the merge proves the policies and generated code, not every IDE and device combination.

A skipped test is not a pass

PR #5538 found that screenshot skip markers used output names while the report parser looked only at Java class names. The marker disappeared, and the surrounding start and finish lines counted the test as a pass.

Correcting that mapping exposed 11 hidden skips on watchOS, six on tvOS, and two or three on every other port. An unknown marker now fails the reporting contract instead of disappearing.

The same investigation fixed Linux VideoIO. The CI image lacked the codec plugins it claimed to test. GStreamer returned a partial pipeline plus an error for a missing element, but the port ignored the error. The reader also asked a paused pipeline for a normal sample when the decoded frame was still the pre-roll buffer. Linux now installs the codecs, rejects partial pipelines, pulls the pre-roll frame correctly, and reports only encoders and decoders present in the GStreamer registry.

Google Sign-In now runs in an arm64 simulator

PR #5544 moves the iOS Google Sign-In integration from the old bundled 5.x framework to GoogleSignIn 7.1. The old framework had an arm64 device slice but no arm64 simulator slice. On an Apple Silicon Mac, the linker selected the device slice and rejected it.

Version 7.1 builds from source for the selected SDK. The native bridge now uses completion handlers and the current token API. We stopped at 7.1 because later versions introduce Swift dependencies that would force modular headers into every generated Podfile, including projects unrelated to Google Sign-In.

Small-object pages can return to the OS

ParparVM's BiBOP allocator segregates small objects by size class. Before PR #5540, empty pages stayed in that allocator forever. A temporary peak in small objects could therefore crowd out a later image buffer, Metal texture, or glyph atlas even after the small objects were collected.

The collector now keeps a 4 MB warm pool and releases the slot area of surplus pages. On Apple platforms it uses MADV_FREE_REUSABLE, which reduces the phys_footprint value used for memory pressure. A controlled integration test warmed 192 MB of 256-byte objects and then allocated two identical large-buffer sets. The measured peak fell from 466,224 KB to 287,824 KB, while the benchmark geomean stayed at 1.0031 relative to the no-release control.

Arm64 retains roughly one quarter of each 64 KB allocator page because its 16 KB system page also contains the allocator header. Moving that header would require a larger allocator redesign.

A retired URL now has somewhere useful to go

PR #5546 adds a /download/ compatibility page for old plugin and Ant-era links. New projects go to Initializr and Getting Started. Existing legacy projects go to the Maven migration guide.

The general 404 page now offers search plus direct routes to setup, documentation, demos, pricing, community, and legacy downloads. It is marked noindex, nofollow; normal pages remain indexable. The constrained _redirects file did not change.

Initializr now generates projects on Codename One 7.0.265 through PR #5533.

The work around the app is part of the app

The GUI Builder rewrite is about keeping control close to the artifact you ship. Forms, CSS, generated Java, and responsive behavior now share one inspectable workspace. The debugger, port reports, memory allocator, login bridge, and recovery pages all remove places where the toolchain previously hid the real state.

Security follows the same direction. Last week App Shield moved the final trust decision from the phone to the backend. Saturday's App Hardening post covers the binary layer. The open portable encrypted database PR addresses data at rest and is still under review.

These controls solve different problems. Together they move Codename One toward a secure default at each boundary: readable code in the binary, modified clients calling a server, and plaintext data on disk. That is a more useful security lead than one large checkbox with an impressive name.

App Shield: Your Server Should Not Trust the App Calling It

Shai Almog — Fri, 14 Aug 2026 14:11:17 +0000

Any security check that runs only on a phone can be patched out on that phone. App Shield moves the final decision to your server by attaching a short-lived, server-verified attestation token to protected requests.

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.

Greetings from Thailand. My family dragged me here for a forced vacation. It is a lovely country, but beaches, sunshine, and the sea aren't really my thing. The GitHub Actions downtime didn't help either, so progress was slower than usual this week. Several interesting PRs are still in progress, and we chose not to rush them.

This week in one page

App Shield connects device integrity, certificate pinning, and your backend instead of asking the app to trust its own verdict.
OpenType fonts now work as .otf files across the supported ports. The CSS compiler also catches several font failures before they reach a device.
Windows desktop builders are moving to newer machines. This is the older JavaSE Windows target, not the native Win32 target.
The Maven repository migration has entered phase two. Newly generated projects now point dependencies and plugins at our R2 repository.
push.codenameone.com redirects to the new cloud service on Saturday, August 8.

A local check is not a security boundary

Codename One App Shield is an Enterprise application-attestation layer. It asks Apple App Attest or Google Play Integrity for a hardware-backed statement, verifies that statement through the Codename One service, and gives the app a short-lived ES256 token. Your backend verifies that token before it performs a sensitive operation.

We already serve several banking customers, and high-security requirements have shaped Codename One for years. Java is part of that fit. These teams get mature analysis tooling, a familiar type system, and one application codebase to review instead of separate iOS and Android implementations.

Java is not a security boundary by itself. The build pipeline adds useful friction for an attacker, but determined attackers can still reverse engineer a client they control.

Control	Default	What it does
iOS native compilation	On	ParparVM translates the application's Java bytecode to C and then builds a native binary.
Obfuscation	On	Removes useful names and makes static inspection harder.
Debug flags	Off in release builds	Blocks the ordinary production debugging path.
Root, jailbreak, Frida, and accessibility checks	Opt-in	Adds device-side signals or launch-time gates for specific risks.
Secure screen and clipboard restrictions	Opt-in	Reduces capture and clipboard exposure. It is not a keylogger defense.
App Shield	Enterprise opt-in	Makes your backend act on a server-verified attestation token rather than a client boolean.

The distinction in the last row is the point. A modified app can force a local isDeviceCompromised() call to return false. It cannot mint a valid token signed by a key your server trusts.

From hardware statement to protected API

App Shield joins the platform attestation provider, the Codename One verification service, and your backend:

The nonce prevents a captured platform statement from becoming a permanent replay credential. The token identifies the expected package and platform, carries the policy decision, and can bind to one request body. The service can also include signals for root, jailbreak, hooking frameworks, emulators, debuggers, repackaging, or untrusted accessibility services.

Your backend remains the enforcement point. The client reports what it sees. The service evaluates the attestation and policy. Your API decides whether to move money, return personal data, request step-up authentication, or reject the call.

The app-side setup is a host list

Enable the injected engine in codenameone_settings.properties:

codename1.arg.shield.enabled=true

Then register the hosts that should receive a token:

AppShield.init(new ShieldConfig()
        // A request without a token must not leave the device.
        .protect("api.mybank.example", HostPolicy.ENFORCED)
        // Other subdomains get a token when one is available.
        .protect("*.mybank.example", HostPolicy.PROTECTED));

ConnectionRequest request = new ConnectionRequest(
        "https://api.mybank.example/transfer", true);
NetworkManager.getInstance().addToQueueAndWait(request);

When App Shield owns the application's network guard, ConnectionRequest, Rest, RequestBuilder, and other code built on NetworkManager pass through it automatically. App Shield attaches X-CN1-Attest on the network thread and checks the certificate chain against the current SPKI pin set. An unregistered host is untouched.

The two policies encode different outage choices:

Policy	If no valid token is available
`HostPolicy.PROTECTED`	Send the request without a token. The backend can degrade or reject it.
`HostPolicy.ENFORCED`	Fail before the request leaves the device. Use this for the few endpoints where an unverified request is never acceptable.

If your application already has a network guard

NetworkManager accepts one NetworkGuard and seals that slot after the first call to setNetworkGuard(). In the usual setup, call AppShield.init() at the top of your application's init(Object) method, before any library or application code installs a guard.

If another guard is installed first, App Shield cannot replace it. Initialization continues, but ordinary requests receive neither the attestation token nor App Shield's certificate-pin check. This includes hosts marked ENFORCED: without the shield guard, nothing sees that policy before the request leaves the device.

An application that needs its own guard must install one composite guard and forward every callback to App Shield's guard:

final NetworkGuard shield = AppShield.getNetworkGuard();

NetworkManager.setNetworkGuard(new NetworkGuard() {
    public void beforeRequest(ConnectionRequest request) throws IOException {
        request.addRequestHeader("X-My-Trace", newTraceId());
        shield.beforeRequest(request);
    }

    public boolean isCertificateCheckRequired(String url) {
        return shield.isCertificateCheckRequired(url);
    }

    public void checkCertificates(ConnectionRequest request,
            ConnectionRequest.SSLCertificate[] certificates) throws IOException {
        shield.checkCertificates(request, certificates);
    }

    public String[] interestingResponseHeaders() {
        return shield.interestingResponseHeaders();
    }

    public void afterResponse(ConnectionRequest request, int responseCode,
            String[] headers) {
        shield.afterResponse(request, responseCode, headers);
    }
});

AppShield.init(new ShieldConfig()
        .protect("api.mybank.example", HostPolicy.ENFORCED));

AppShield.getNetworkGuard() is safe to call before init() because the guard reads the configuration when it handles a request. Forwarding only beforeRequest() is not enough. The certificate callbacks enforce the pin set, while the response callbacks let App Shield discard a rejected token. If your guard also captures response headers, return the union of both guards' header names and preserve that order when passing App Shield its values.

The simulator now has Simulate > App Shield controls for rejected attestations, expired tokens, compromised-device signals, and forced certificate-pin mismatches. That makes the failure path testable without misconfiguring a live server.

The public API lives in the open-source core. A build without the Enterprise engine degrades to a documented no-op, so shared code still compiles and runs. A cloud build that explicitly requests shield.enabled=true without entitlement fails with an explanation instead of silently producing an unprotected binary.

What App Shield does not protect

App Shield does not make an application unhackable. It raises the cost of calling a protected backend from a modified app and gives the server a cryptographically verifiable input for its policy.

A genuine attested device can still relay requests for an attacker. Short token lifetimes and payload binding reduce replay, but they do not replace backend authorization, rate limits, or checks on the business operation itself.

It also cannot cover traffic it cannot see. ConnectionRequest-based APIs get automatic tokens and pinning. A third-party native HTTP client needs a token attached manually. A BrowserComponent can receive a token for its initial navigation, but requests made by the loaded page remain outside the framework. WebSocket handshake headers are not available through the platform socket on iOS or in the browser, and WebSocket certificate pinning is not exposed.

Certificate pinning has its own operational risk. App Shield pins public keys rather than whole certificates, so a certificate renewal on the same key does not break the app. You should still roll out the server policy in monitor mode first, measure the would_deny traffic, and only then reject requests.

The complete wire format, failure statuses, transport boundaries, pin lifecycle, and backend examples are in the App Shield developer guide.

OpenType fonts now work without renaming

PR #5508 makes .otf a supported font extension across iOS, tvOS, watchOS, Android, JavaSE, JavaScript, Windows, and Linux. This corrects an inconsistent path where some tools could parse an OpenType font but device packaging ignored its extension.

You can now keep the original file in or below the directory containing your CSS:

@font-face {
    font-family: "Brand Display";
    src: url("fonts/BrandDisplay.otf");
}

Title {
    font-family: "Brand Display";
}

The CSS compiler reads local fonts during the build. It now reports a missing file, an unreadable font, a missing PostScript name, a path outside the CSS directory, or two different files that would collide after packaging. Web font formats such as .woff remain unsupported.

New builders for the JavaSE Windows target

We are bringing down the old Windows desktop build machines and replacing them with newer servers. These machines build the older JavaSE-based Windows desktop target. They are separate from the new native Win32 target.

The old builders crashed too often and held this target behind the rest of the toolchain. We expect the replacements to reduce those failures and finally make Java 17 projects available for this desktop build path. That work is still a server rollout, so treat JDK 17 as the intended result until we finish validation on real builds.

New projects now resolve Codename One through R2

Phase two of the Maven repository migration merged today. The application archetype, library archetype, and Initializr now put https://repo.codenameone.com/maven2 in both repository lists.

Maven keeps ordinary dependencies and build plugins in separate lists. Both blocks matter:

<repositories>
    <repository>
        <id>codenameone</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases><enabled>true</enabled></releases>
        <snapshots><enabled>false</enabled></snapshots>
    </repository>
</repositories>

<pluginRepositories>
    <pluginRepository>
        <id>codenameone-plugins</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases><enabled>true</enabled></releases>
        <snapshots><enabled>false</enabled></snapshots>
    </pluginRepository>
</pluginRepositories>

Newly generated builds now resolve Codename One releases through R2. Existing projects can add the same blocks before the planned August 28 cutover. We will stop publishing new versions to Maven Central on that date if the observation period remains clean. The archetype lookup itself still starts on Central; moving that lookup is phase three.

The repository migration post explains the dates, artifact retention, signatures, and safeguards against partial releases.

The push hostname switch happens Saturday

On Saturday, August 8, we will redirect push.codenameone.com to cloud.codenameone.com. We announced the new service and compatibility endpoint in the Push V3 release post.

Existing push code should continue to work because the new service accepts the classic request format. Before the redirect, you can test the exact path by changing only the hostname on your server:

-https://push.codenameone.com/push/push
+https://cloud.codenameone.com/push/push

Send a real notification to every platform you support. Test a visible notification, a data payload, and a cold start. If the result differs from the old host after Saturday's switch, open an issue or contact us through the website as soon as possible.

App Shield is the larger direction behind this release: security controls should compose across the app, the build, and the server. OpenType support, new Windows builders, the R2 migration, and the push cutover are smaller changes, but they follow the same rule. The dependable path should be the normal path, and failures should surface where we can act on them.

Why Codename One Is Moving Beyond Maven Central

Shai Almog — Tue, 11 Aug 2026 14:16:04 +0000

Codename One is starting a staged move from Maven Central to a repository we operate on Cloudflare R2.

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 is not a story about Maven Central being bad. Sonatype runs expensive public infrastructure and has every right to define usage limits or sell a commercial service. Our release shape is simply a bad fit for those limits, and passing that infrastructure bill to Codename One users would make less sense than serving the same signed Maven layout ourselves.

PR #5497 implements phase one. It reduces what each release publishes and adds dual publication to R2. Maven Central remains authoritative during this phase.

We first talked about the repository move in Friday's release post.

Our dashboard is not a near miss

The current Central Publishing usage dashboard reports:

Measure	Codename One	Dashboard guideline	Reported use
Storage	2.12 GB	80 MB	2,652%
Files	19,962	1,000	1,996%
Releases	27	7	386%

That screenshot also explains Sonatype's position. It says the guidelines are soft, describes adjustments for qualifying open-source projects, and offers a commercial Publisher Pro route. We are an unusually heavy publisher, not an innocent bystander being charged for one small JAR.

The question is who should carry the cost. In Open Source Bait and Switch, I argued that monetization pressure often lands on small open-source vendors while the largest companies capture much of the value. Maven hosting is a different product and Sonatype is not changing our license. The same asymmetry is still relevant: charging a small framework company does not necessarily collect from the enterprise organizations receiving the largest downstream benefit.

We can provide package hosting free to Codename One developers on infrastructure that matches our release process. That is the more sustainable answer for us.

The migration has three visible dates

Date	Phase	User impact
July 31, 2026	Reduce release payload and start dual publishing	None. Central remains authoritative.
August 7, 2026	Generated projects and Initializr add the Codename One repository	New projects receive the repository automatically. Existing projects can add it manually.
August 28, 2026	Stop publishing new Codename One versions to Central, if the dual-publish period is clean	Existing projects need the Codename One repository to discover future versions.

Dates are more useful than “next week” in a migration document. If validation changes the schedule, we will update this post before changing the source of new releases.

The POM change

Existing projects do not need to change during phase one. To prepare a project for new releases after the cutover, add both a repository and a plugin repository:

<repositories>
    <repository>
        <id>codenameone</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

<pluginRepositories>
    <pluginRepository>
        <id>codenameone-plugins</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </pluginRepository>
</pluginRepositories>

The plugin repository is not redundant. Maven resolves build plugins and ordinary dependencies through separate repository lists. A project with only <repositories> can download a runtime artifact and still fail to discover a future codenameone-maven-plugin.

Next week's Initializr and archetype change will generate this configuration. Existing projects can add it at any time; the repository uses standard Maven layout and does not change dependency coordinates.

We were publishing the same bytes repeatedly

The real Codename One 7.0.258 release published 44 artifacts and 127 JARs totaling 229.5 MB. The core JAR itself is only 4.49 MB. Most of the weight came from shaded fat JARs that republished the same third-party libraries each week.

Phase one reduces the measured release payload to 76.9 MB, a 66 percent reduction:

	Per release	Versions in 8 GB	Approximate history at 65 versions per year
Before	229.5 MB	35	6 months
After	76.9 MB	106	1.6 years

The changes are deliberately targeted:

Five unused jar-with-dependencies attachments stop being published. Builder bundles still contain what they need.
Stable designer, javase-svg, and sqlite-jdbc artifacts are frozen at pinned versions instead of being copied into every release.
The headless CSS command moves out of the 43.5 MB Resource Editor fat JAR.
A new css-cli module carries that command in a 28 KB JAR.

The CSS compiler itself had already been separated. Its command-line driver had not. Moving that driver avoids launching the complete Swing editor dependency graph for a headless build.

This optimization would not get us under the dashboard guidelines. It is still worth doing. It reduces upload time, metadata churn, retention pressure, and the number of bytes a failed release has to retry.

R2 is static hosting, which is what Maven needs

A release repository does not need a database-driven artifact server in the request path. Maven needs immutable files in a known directory layout, metadata, checksums, and signatures.

The release pipeline uploads:

maven2/com/codenameone/<artifactId>/<version>/...
maven2/com/codenameone/<artifactId>/maven-metadata.xml
maven2/com/codenameone/maven-metadata.xml
maven2/archetype-catalog.xml

The R2 publication reuses the tree already staged for Central. It includes MD5, SHA-1, SHA-256, SHA-512, and .asc signatures. There is no second Maven build that could produce different bytes.

Cloudflare's edge cache and object storage should reduce download latency and remove Central throttling from our release path. We also expect releases and CI to become faster and more stable because publication no longer depends on a second service accepting our volume at that moment. Those are expectations, not measurements yet. We will compare publish time, artifact resolution time, cache behavior, and failure rate during dual publication.

Static hosting still needs release semantics

Object storage will happily accept a partial or overwritten release unless the publishing scripts stop it. The phase-one tooling adds those rules:

Released bytes are immutable. An upload fails if the same path already contains different content.
A release is invisible until every core and editor artifact is present.
A per-release completion marker is written only after all uploads succeed.
maven-metadata.xml is rebuilt from the bucket listing, never from the one-version staging tree.
Metadata advertises only versions with a completion marker.
Upload uses a copy operation that cannot delete older versions.
Frozen dependencies are seeded from Central and verified against their checksums.

Cloudflare can cache a 404 just before a new artifact appears. The runbook therefore requires a cache rule that does not store 4xx and 5xx responses. Release polling also uses a cache-busting query so a stale negative cannot turn a successful upload into a false release failure.

Retention: the guarantee and the likely window

We will guarantee at least six months of historical Codename One versions in the new repository. The optimized payload currently fits roughly 106 releases in the planned capacity, which is about 1.6 years at the recent pace.

The guarantee is shorter than the estimate because release contents and frequency can change. We would rather guarantee a window we can defend and retain more in practice than publish a long promise that quietly fails.

Freezing stable packages also means “history” is no longer one full copy of every byte per weekly tag. A future version can depend on a pinned stable artifact while the frequently changing core keeps its own version cadence.

Versions already on Maven Central are not deleted by this move. The retention policy applies to the repository we operate and to future availability, not to removing the public history that Central already stores.

What can still go wrong

The red-team list is part of the design:

A partial upload is advertised. Completion markers and metadata-last publication prevent it.
A retry changes released bytes. The overwrite guard fails the release.
A stale cached 404 hides a new file. The cache rule and cache-busted poll address it.
A project adds only the dependency repository. Generated POMs include <pluginRepositories> too.
A frozen artifact remains available only on Central. The seed step copies and verifies every pinned dependency before the final cutover.
R2 is slower in a real region. The observation window measures this before Central publication stops.
Three release tags arrive while one is running. GitHub Actions can replace a pending member of a concurrency group. The current runbook requires pushing release tags one at a time until dispatch is made durable.

The last item is not polished away. The repository removes one availability dependency, but it does not turn GitHub Actions into a release queue.

Why this should be mostly seamless

Coordinates, version numbers, signatures, checksums, and normal Maven resolution remain unchanged. New projects receive the repository automatically next week. Existing projects need one POM block before they request a post-cutover version.

That is the whole user-facing migration. The work underneath it is larger because package hosting is part of the product supply chain. If we do this well, developers will notice faster and more reliable resolution, not a new thing they have to learn.

A Polyline Is Not a Route

Shai Almog — Mon, 10 Aug 2026 14:43:58 +0000

A polyline can draw the points you give it. It cannot discover the road between them.

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.

PR #5480 adds com.codename1.maps.routing, a portable route model and service layer for road geometry, distance, duration, waypoints, alternatives, legs, steps, and encoded polylines.

We talked about routing in Friday's release post.

The two-line route

For the common case, give Routing a map and two coordinates:

MapView map = new MapView();
Routing.showRoute(
        map,
        new LatLng(38.8977, -77.0365),
        new LatLng(38.8894, -77.0352)
);

The call returns immediately. The routing service finds the best route, the API adds its polyline, and the map frames the result.

showRoute(...) is intentionally small. It is useful when the line itself is the result. An application that needs error UI, custom styling, ETA, or alternatives should use the callback route.

Own the result when it matters

RouteRequest request = new RouteRequest(origin, destination)
        .setTravelMode(TravelMode.DRIVING)
        .addWaypoint(coffeeStop)
        .setAlternatives(true)
        .setSteps(true);

Routing.findRoute(request, new RouteCallback() {
    public void routesFound(List routes) {
        Route best = (Route) routes.get(0);

        map.addPolyline(best.toPolyline()
                .setStrokeColor(0xff5722)
                .setStrokeWidth(6));
        map.fitBounds(best.getBounds(), 40);

        distanceLabel.setText(
                Math.round(best.getDistanceMeters() / 1000.0) + " km");
        etaLabel.setText(
                Math.round(best.getDurationSeconds() / 60.0) + " min");
    }

    public void routeFailed(String message, Throwable error) {
        ToastBar.showErrorMessage(message);
    }
});

The callback is invoked exactly once and always later on the Codename One EDT, even if a custom service responds synchronously, responds from a worker thread, responds twice, or throws after responding. The facade contains those service errors so application timing does not depend on the provider implementation.

The model exposes:

One or more route alternatives
Total distance and duration
Geographic bounds
Route geometry
Legs between waypoints
Step instructions and maneuver locations
Provider metadata

PolylineCodec supports precision 5 and precision 6 encoded geometry. That lets a service retain the compact wire format and decode it only when a Polyline is needed.

OSRM makes the first run easy

The default RouteService is OsrmRouteService. It needs no API key, so the two-line example can work without provider signup.

That default points to the public OSRM demonstration server. The server has no production SLA and asks clients to keep usage light. It can reject large or abusive workloads, and its public profile is configured for cars.

This means:

DRIVING is appropriate for a quick test.
WALKING or CYCLING against the default demo can still return car routing.
A shipping application should use a provider and capacity it controls.
Offline routing requires another implementation.

Travel mode is a request, not a guarantee. A RouteService reports what it supports, and an application should not label a result “walking” when the active backend only has a car graph.

Point OSRM at infrastructure you control

OSRM is open source and can be self-hosted. If your server exposes an OSRM-compatible route endpoint, install it as the application service:

Routing.setService(new OsrmRouteService(
        "https://routing.example.com"
));

Use the exact constructor and endpoint configuration supported by your selected release. The architectural point is that application code still consumes Route, not provider JSON.

For a different provider, implement RouteService:

public final class CompanyRouteService implements RouteService {
    public String getId() {
        return "company-routing";
    }

    public boolean isAvailable() {
        return credentialsAreReady();
    }

    public void findRoutes(RouteRequest request, RouteCallback callback) {
        // Translate the portable request, call the provider,
        // then return portable Route objects through the callback.
    }
}

Routing.setService(new CompanyRouteService());

That seam supports commercial providers, a company gateway, an offline engine, or a route service with domain constraints such as truck height and hazardous materials.

The maps API and routing API stay separate

MapSurface displays geometry. RouteService discovers geometry. Keeping them separate avoids tying a route provider to one renderer.

The same route can be:

Drawn on a native or vector map
Styled according to traffic or accessibility
Summarized as distance and ETA
Saved as an encoded polyline
Compared with alternatives
Sent to another screen without retaining the map component

The API does not yet claim turn-by-turn navigation, rerouting, traffic prediction, offline map packages, or voice guidance. Those are stateful products with location updates and provider-specific rules. This release provides the route result that those systems need, without naming a static polyline “navigation.”

Production checklist

Before shipping:

Choose a routing service with terms, capacity, data coverage, and travel profiles that fit the application.
Report route failures to the user. The no-callback showRoute(...) convenience method cannot do that.
Verify units before displaying them. The model uses meters and seconds.
Test dateline crossing, unreachable points, ferries, tolls, and waypoint order for the markets you serve.
Keep provider keys out of client code when the provider expects a server-side secret.
Attribute map and routing data according to each provider's license.

A route is an answer from a changing road graph, not a decorative line. The new API finally represents it that way.

Next in the series: why Codename One is starting a staged move beyond Maven Central.