feat(android): getMemoryUsage and log — ratchet 102 -> 100

The first two Android actions that need no Activity at all. Both reach a static class and stop, so neither depends on anything the app hands over — which makes them the honest start of Tier 0, rather than getDeviceInfo, whose display metrics and package info do need it.

Ratchet 102 → 100.

getMemoryUsage is not the iOS action wearing a different name

iOS asks the kernel for this process's resident size through task_info. Android asks the JVM about its own heap through java.lang.Runtime — and those are different quantities. totalMemory() is what the managed heap has reserved, not what the process holds, and every native allocation this bridge makes is outside it.

So the platforms answer with different keys, and that's correct rather than sloppy:

Only usedMB is shared, and even that measures something else. Making them agree would mean one of them lying about which number it took.

Split the same way the device module is: readMemory does the JNI work and returns a plain struct, renderMemory turns it into bytes and touches no Java. The rounding is integer arithmetic rather than a float format, for the reason bridge_mobile_device.zig gives for the same figure on iOS — it becomes a property of a function you can assert, not of a format you have to observe.

log is here for the seam, not the code

One line of Kotlin. What it buys is the first static method call and the first native that answers with a boolean.

Void wouldn't work: the Kotlin has to be able to tell a written line from a declined one, or it logs twice or not at all. And the "CraftBridge" tag is kept character for character — anyone filtering logcat on it is filtering on a string, and changing it because Zig now emits the line would break a filter that has nothing to do with this migration.

Two bugs, both caught by their own tests

{d:0>2} renders +74 on this toolchain — a sign, not a zero. The reply read 117.+74 and stopped parsing at the dot. Padded by hand now, with the reason recorded beside it.

The rounding test asserted the opposite of what it looked like. It computed the half-way boundary as 1024*1024/200, which truncates to 5242 — below the true 5242.88 — so "half rounds up" was actually testing that just-under-half rounds down. Both boundaries are written out explicitly now.

JNI additions

CallLongMethod, plus GetStaticMethodID / CallStaticObjectMethodA / CallStaticIntMethodA. A static call is a different table entry from an instance one and takes the class rather than the receiver — passing a jclass to CallObjectMethod compiles and is undefined at runtime.

Verified

zig build test:android → 63 tests, 11/11 steps · both .so build · the generator's 10 tests still pass.

Next

clipboardRead/clipboardWrite — the first that need getSystemService and an Activity, and the first with a real null path (primaryClip can be absent, and the Kotlin returns "" for it).