The background-task quartet resolves success and schedules nothing

All four background-task methods on Android resolve successfully and do no work at all.

@JavascriptInterface
fun registerBackgroundTask(taskId: String) {
    try {
        // WorkManager tasks don't require explicit registration, just track them
        activity.runOnUiThread {
            webView.evaluateJavascript(
                "window._craftBgTaskResolve && window._craftBgTaskResolve({taskId: ${jsQuote(taskId)}, registered: true})", null)
        }
    } catch (e: Exception) { ... }
}

The comment says "just track them" and nothing is tracked — there is no field, no map, no set. registerBackgroundTask resolves {registered: true}.

scheduleBackgroundTask is explicit about it:

// Note: Full WorkManager implementation requires adding the dependency
// implementation 'androidx.work:work-runtime-ktx:2.9.0'
// This is a placeholder that shows the API structure

and then resolves {taskId, scheduled: true, delay}. Nothing is enqueued, no WorkRequest is built, and the dependency is not in the generated build.gradle.kts.

cancelBackgroundTask resolves {cancelled: true} for a task that was never scheduled, and cancelAllBackgroundTasks resolves for all of them.

Why the shape is the problem

A page that schedules a nightly sync and checks the reply is told it succeeded. Nothing runs, and there is no later signal — no failure, no timeout, no event. The only way to notice is that the work never happens, which on a background task can take days to attribute.

_craftBgTaskReject is already assigned by the injected JS, so there is somewhere honest to send this.

Two ways out

• Implement it. androidx.work:work-runtime-ktx in the app template, OneTimeWorkRequestBuilder with the Constraints the API already accepts (requiresNetwork, requiresCharging, delay), and WorkManager.getInstance(activity).enqueueUniqueWork(taskId, ...). cancelUniqueWork(taskId) and cancelAllWork() then mean something, and registerBackgroundTask can go — the comment is right that WorkManager needs no registration.
• Reject. "Background tasks require the WorkManager dependency", which is what signInWithGoogle and scanQRCode already do for their own missing setup, and is honest today.

Either is better than the current answer. The choice is a product one — whether craft apps carry WorkManager — which is why this is an issue rather than a patch.

Not migrated to Zig

android_conformance_test.zig records all four as deliberate deferrals. Porting a method whose whole body is a fabricated success would spread the fabrication into a second language, which is the same reason setBadge (#148) and the AR trio are not migrated.

Related: #127, #148, #154, #157, #159, #169, #175 — replies that are sent but do not mean what they appear to.

Resolved by e91c493 and CI follow-up 3cb19a8. Android now rejects the background-task quartet explicitly instead of reporting fabricated success for work it cannot execute; documentation and generator regression coverage were updated accordingly. The final implementation commit passed CI, SBOM, Binary Size, and Benchmark.