Open Measurement SDK for Android 1.6.10 introduces a new way to run verification scripts for native ad sessions: Android’s Jetpack JavaScriptEngine, running JS in an isolated sandbox process instead of a `WebView`.
It’s opt-in, faster to spin up, and less likely to affect app responsiveness.
What’s Different?
Historically, OM SDK ran verification scripts for native ad sessions in a `WebView`. With OM SDK 1.6.10, the sessions can execute them through Android’s JavaScriptEngine sandbox `androidx.javascriptengine` instead. This is the same out-of-process JS engine API that Android now recommends for running non-interactive JavaScript outside of a `WebView`.
This change is non-breaking to the way this works prior to 1.6.10:
- Native ad sessions can now use the `JavaScriptEngine`, with automatic fallback to the existing internal `WebView` executor if the sandbox isn’t available.
- Apps that don’t integrate the sandbox keep working exactly as before.
Note: HTML/JavaScript ad sessions, in which the integrator provides a `WebView`, do not yet support the `JavaScriptEngine`; such support is being investigated by the OM SDK team as a potential follow-up to this release.
Why should I change what I am currently doing?
There are a number of reasons to make this change, which improves performance and reliability. As noted in Android’s own documentation, running JS in the sandbox instead of a `WebView` means:
- Lower resource consumption — no `WebView` instance needs to be allocated just to run a verification script.
- Process isolation — scripts run in a separate sandboxed process from the app’s main process, so a crash or memory-limit breach in the sandbox doesn’t take down the host app.
- Low-overhead concurrency — multiple isolated JS environments can run side by side cheaply, useful when several ad sessions are active at once.
Benchmark
To benchmark the changes we used a low end device, 10 cold-start iterations, and using identical devices to build across all three runs. The Baseline is the same app flow with no OM session created at all. This is just the floor cost of the flow with zero OM work, that is used to isolate session-creation overhead.
| Run | First session creation (median) | Frame overrun (P99) |
| Baseline (no OM session) | 0 ms | 114.51 ms |
| JSEngine | 11.07 ms | 119.08 ms |
| WebView | 268.51 ms | 589.07 ms |
With `JavaScriptEngine`, the first OM session takes \~11 ms, and the worst-case frame overrun (~119 ms) sits right next to the no-OM baseline (\~115 ms). WebView, by comparison, adds \~268 ms of median creation time and pushes P99 frame overrun to \~589 ms.
For publishers, that gap shows up as smoother ad-load frames and less risk on the first render. This is particularly impactful on low-end devices where a cold `WebView` spin-up is most expensive.
What publishers should do to implement
Adopting JSEngine is opt-in and requires a small activation-time change. The steps are as follows:
- Update to OM SDK Android 1.6.10 or later.
- Add the `androidx.javascriptengine` dependency.
- Create a connected `JavaScriptSandbox` on API 26+ (see Android’s “Basic Usage” guide for creating and managing the instance) and expose it to OM SDK through a `JavaScriptSandboxProvider` at activation:
```java
Omid.activate(context, () -> javaScriptSandbox);
```4. Keep the sandbox alive for the app’s lifetime — Android permits only one `JavaScriptSandbox` instance per app, so it should be created once.
If the sandbox isn’t available on a given device, or the provider returns `null` by the time the OM SDK creates the session, it automatically falls back to the existing `WebView` executor.
The Bottom line
`JavaScriptEngine` support for Android in OM SDK 1.6.10 gives publishers a faster path to creating native OM ad sessions, with a straightforward, small integration step that does not create risk to apps that don’t adopt it. You can review the full API details, requirements, and caveats in Android’s JavaScriptEngine documentation.
Sid Polo
Senior Software Engineer | Mobile Specialist
DeliveryHero