IAB Tech Lab published a technical post on October 1, 2026, setting out how version 1.6.10 of its Open Measurement SDK for Android can run verification scripts for native ads inside Android's Jetpack JavaScriptEngine, a sandboxed process, rather than inside a WebView. The post was written by Sid Polo, a senior software engineer at DeliveryHero, and pairs the change with benchmark figures from a low-end device.

In Short

On October 1, 2026, IAB Tech Lab described a new option in the toolkit that lets Android apps check whether ads were seen: the checking scripts can now run in a small, walled-off engine instead of a hidden mini web browser. In a test on a low-end phone, the walled-off route got the first check going in about 11 milliseconds instead of about 268, which matters to app publishers because ad loading and measurement compete for the same slow moments. Apps that do nothing keep working exactly as before, and ads built in HTML formats are not covered yet.

What the post describes

According to IAB Tech Lab, the Open Measurement SDK (OM SDK) has historically run verification scripts for native ad sessions inside a WebView. From version 1.6.10 of the Android library, those sessions can instead execute through androidx.javascriptengine, which the post describes as the out-of-process JavaScript engine API that Android now recommends for non-interactive JavaScript outside a WebView. The post characterises the route as "opt-in, faster to spin up, and less likely to affect app responsiveness."

Two design choices limit the exposure for apps that do not take part. The first is fallback. If the sandbox is unavailable on a device, or if the provider returns null by the time the SDK creates a session, the SDK reverts to its existing internal WebView executor. The second is scope. Apps that do not integrate the sandbox keep working exactly as before, and the post describes the change as non-breaking. HTML and JavaScript ad sessions, in which the integrator supplies the WebView, "do not yet support the JavaScriptEngine"; the OM SDK team is investigating support as a potential follow-up, the post states.

The rationale is borrowed from Android's own documentation. Running scripts in the sandbox, the post says, means lower resource consumption, since no WebView instance has to be allocated just to run a verification script; process isolation, so that a crash or memory-limit breach in the sandbox does not take down the host app; and low-overhead concurrency, with several isolated JavaScript environments running side by side while multiple ad sessions are active. The post does not give a release date for version 1.6.10.

The benchmark figures

The benchmark compared three runs on a low-end device, with 10 cold-start iterations and identical devices used to build across all three. The baseline run created no OM session at all. According to the post, that is the floor cost of the app flow with zero measurement work, used to isolate session-creation overhead.

RunFirst session creation (median)Frame overrun (P99)
Baseline (no OM session)0 ms114.51 ms
JSEngine11.07 ms119.08 ms
WebView268.51 ms589.07 ms

Calculated from the table, median first-session creation took 257.44 ms longer on the WebView path than on the JavaScriptEngine path, a ratio of roughly 24 to 1. At the 99th percentile, which the post treats as the worst-case frame overrun, the JavaScriptEngine path sat 4.57 ms above the no-session baseline, about 4 percent. The WebView path sat 474.56 ms above it, or about 5.1 times the baseline figure.

For publishers, the post says, that gap appears as "smoother ad-load frames and less risk on the first render", and it is "particularly impactful on low-end devices" where a cold WebView start is most expensive. What does the evidence amount to? One author's measurements on a single device that the post does not name, with no Android version, no WebView version and no account of how frame overrun was captured. Figures for mid-range and high-end hardware, memory use and battery are absent, and the post does not say whether the benchmark reflects a production deployment at DeliveryHero. The numbers are one engineer's test result rather than an independent measurement.

How Android's sandbox works

Android's developer documentation, last updated February 26, 2026 according to the page footer, describes the JavaScriptEngine library as a way for an application to evaluate JavaScript "without creating a WebView instance." The page lists four advantages for non-interactive evaluation: lower resource consumption, use from a Service such as a WorkManager task, multiple isolated environments with low overhead, and the ability to pass large amounts of data through an API call.

Sandbox and isolates

Two objects carry the design. A JavaScriptSandbox is a connection to the out-of-process engine; a JavaScriptIsolate is an execution context inside it. According to the documentation, applications must call JavaScriptSandbox.isSupported() before any other sandbox method, and creating a sandbox on an unsupported device throws a SandboxUnsupportedException. Support starts at API 26 and also depends on the WebView implementation on the device, which in turn determines which optional features exist.

Allocation is described as "fairly expensive." "Only one JavaScriptSandbox instance per application is allowed," and a second attempt throws an IllegalStateException. Applications that need several execution environments allocate several isolates instead. An isolate can be created and used from any thread, keeps its state between calls, so data created in one call can be processed in a later one, and provides what the documentation calls "weak security boundaries" between scripts of different origin. Closing an isolate that is still running code, meaning one with an incomplete Future, produces an IsolateTerminatedException.

Crash behaviour

All JavaScript runs in a separate sandboxed process. If the code crashes that process, for example by exhausting a memory limit, the application's main process is unaffected. A sandbox crash terminates every isolate inside it, and pending evaluations then fail with IsolateTerminatedException or, depending on the circumstances, the more specific SandboxDeadException or MemoryLimitExceededException. Handling can be centralised through JavaScriptIsolate.addOnTerminatedCallback(), although the callback does not fire when an isolate is closed deliberately with close().

Optional features and data limits

Because features vary with the WebView version, the documentation says each required feature has to be queried through JavaScriptSandbox.isFeatureSupported(...), and methods that may be missing carry a RequiresFeature annotation. Several features govern data handling. Where JS_FEATURE_EVALUATE_WITHOUT_TRANSACTION_LIMIT is supported, evaluation requests are not bound by Binder transaction limits; where it is not, all data to and from the engine passes through a Binder transaction with its general size limit. Results always return as a string, and non-string values must be converted explicitly or an empty string comes back, unless JS_FEATURE_PROMISE_RETURN allows a Promise that resolves to a string. Large byte arrays travel through provideNamedData(...), which requires JS_FEATURE_PROVIDE_CONSUME_ARRAY_BUFFER and a unique identifier that cannot be reused; WebAssembly modules are passed the same way. An IsolateStartupParameters object can cap the heap size and the size of return values and errors. A warning on the page adds that passing improperly escaped data through evaluateJavaScriptAsync(...) "can lead to code injection vulnerabilities", and names provideNamedData(...) as the route for data.

The OM SDK post does not say which of these optional features its integration relies on, or how the SDK allocates isolates among the scripts of different verification vendors.

Adoption as the post lays it out

The post lists four steps: update to OM SDK Android 1.6.10 or later; add the androidx.javascriptengine dependency; create a connected JavaScriptSandbox on API 26 or higher and expose it to the SDK through a JavaScriptSandboxProvider at activation; and keep the sandbox alive for the app's lifetime. The activation call reads:

Omid.activate(context, () -> javaScriptSandbox);

The two documents frame the lifecycle differently. Android's page recommends aligning the sandbox with the component that needs JavaScript evaluation, closing it in onStop() for an Activity or in onDestroy() for a Service, and notes that one Service can wrap evaluation for every component. The OM SDK post, by contrast, describes a single sandbox created once and kept for the life of the app. The positions are reconcilable if the hosting component lives as long as the app, but neither document addresses the other. The post reports timing only, so the memory and process cost of a sandbox that stays resident is not quantified. Under the one-instance limit, the sandbox handed to the OM SDK is also the one any other JavaScript evaluation in the same app would use.

Where the change sits in the OM SDK's history

The OM SDK is the layer through which independent post-bid verification reaches mobile apps. IAB Tech Lab released it in April 2018, and by December of that year it was reaching 2 billion devices, with 17 companies certified. Google integrated it into its Google Mobile Ads and Interactive Mobile Ads SDKs in 2019, and in 2022 announced a switch of Active View for mobile app display inventory in Ad Manager to the SDK, a change that could alter measured viewabilityand measurability for some publishers. A Prebid Mobile community discussion covered in October 2025 described OMID, the interface through which the SDK passes signals to verification scripts, as having over 95 percent market adoption.

Later releases added capabilities in steps. Version 1.3 added audio ad measurement, content-level brand safety and a begin-to-render impression definition. Version 1.5.5 added UniversalAdId support in June 2025. Device attestation arrived in version 1.6 in late 2025, using an adaptation of the IETF Privacy Pass protocol and initially covering Apple and Fire TV devices. Version 11.0 of the Trustworthy Accountability Group's certification, released in July 2026, requires sellers of owned apps in Apple's App Store and Amazon's Fire TV store to support that attestation with OM SDK 1.6 or higher. That requirement concerns different platforms from the Android change, but it shows that the 1.6 line, which includes 1.6.10, now carries certification weight.

Android's ad SDK layer has seen separate performance work in the same period. Google's rewritten Next-Gen SDK for Android entered beta on January 22, 2026 with a published 27 percent reduction in banner request latency, and on July 6, 2026 Google named it the preferred SDK with a sunset for the legacy kit on June 30, 2028. The OM SDK post makes no reference to either step.

Why the executor matters beyond developers

For publishers and the agencies buying their app inventory, the relevance is indirect but concrete. Verification sessions are created on the same device that renders the ad, and the post ties the two executors to very different first-render costs on weak hardware. The signals the SDK gathers feed the viewability and invalid-traffic reporting that buyers see; the post is silent on whether any measured value differs between the two executors.

Because adoption is opt-in and gated by device capability, the executor behind native ad sessions may now vary between apps, and between devices within a single app. How wide that variation becomes depends on figures the post does not provide: the share of Android devices that meet the API 26 and WebView conditions, the number of apps that have integrated the sandbox, and the date on which 1.6.10 reached publishers. How many devices will take the new path? The post leaves the question open.

Timeline

Summary

Who: IAB Tech Lab published the post, which was written by Sid Polo, a senior software engineer and mobile specialist at DeliveryHero. The change affects Android app publishers with native ad sessions, ad SDK integrators, and the verification scripts that run inside OM SDK sessions.

What: Version 1.6.10 of the Open Measurement SDK for Android offers an opt-in route that runs verification scripts for native ad sessions in Android's Jetpack JavaScriptEngine sandbox instead of a WebView, with automatic fallback to the WebView executor. In the post's benchmark on a low-end device, median first-session creation took 11.07 ms on the sandbox path against 268.51 ms on the WebView path, and 99th-percentile frame overrun was 119.08 ms against 589.07 ms, with a no-session baseline of 114.51 ms.

When: The post was published on October 1, 2026. Android's JavaScriptEngine documentation was last updated on February 26, 2026. The post gives no release date for version 1.6.10.

Where: Android apps on API 26 or higher where the device's WebView implementation supports the sandbox. HTML and JavaScript ad sessions are outside the current scope. The benchmark covers one unnamed low-end device.

Why: According to the post, the route lowers resource consumption, isolates sandbox crashes from the host app and lets several ad sessions run cheaply side by side, with the largest effect on low-end devices where a cold WebView start is most expensive.