Chrome Dev 159 (159.0.8144.0) Released for Android — Why Pre-Release Browser Builds Are a Managed-Fleet Risk

The Chrome Release Team has pushed Chrome Dev 159 (build 159.0.8144.0) for Android to Google Play, with a partial changelog available in the Chromium Git log. On the surface this is routine release plumbing — no CVEs, no zero-days, no emergency. So why are we writing about it?

Because every Chrome channel release is a forcing function for a conversation too many enterprises avoid: what browser builds are actually running on your Android fleet, and who approved them? Chrome Dev is a pre-release channel. It updates roughly weekly, ships experimental web platform features, and by design carries code that has not completed the full Beta-to-Stable security and stability bake-in. On a developer's personal handset, that's fine. On a device with access to corporate email, SaaS consoles, VPN profiles, or MDM-enrolled resources, it's an unmanaged expansion of attack surface.

This post is the defensive read on this release: what Chrome Dev 159 is, why pre-release browsers belong on your managed-device blocklist, and how to audit and enforce browser channel policy across an Android fleet today.

What Actually Shipped

• Product: Chrome Dev for Android
• Version: 159.0.8144.0
• Channel: Dev (pre-release, upstream of Beta and Stable)
• Distribution: Google Play
• Security content disclosed: None. The announcement points to the Chromium Git log for changes and the Chromium blog for feature detail. No CVE identifiers are associated with this release notice, and we will not speculate about undisclosed security fixes.

It is worth remembering how Google's channel model works, because it directly affects your exposure math:

Security fixes flow downstream through this pipeline. That means Dev builds can carry regressions and newly introduced bugs that will be caught and fixed before Stable — but Dev users ride that risk window in real time. Historically, Chromium's security reward program and bug tracker show a steady stream of high-severity issues (V8 type confusion, use-after-free in renderer components) that are introduced and corrected within milestone cycles. Running Dev means opting into the introduction side of that equation.

The Defensive Problem: Browser Channel Sprawl on Android

In our IR and assessment work, Android browser risk rarely comes from an exotic mobile zero-day. It comes from three mundane failures:

1. Pre-release or sideloaded browsers on enrolled devices. Chrome Dev, Canary, and Chromium forks installed outside managed Google Play bypass your app vetting, your update cadence, and frequently your per-app VPN and certificate pinning policies.
2. Stale WebView / Android System WebView. Many in-app browsing experiences render through WebView, which updates separately from Chrome. An up-to-date Chrome Stable alongside a six-month-old WebView is a half-patched attack surface.
3. No enforced update floor. Without a minimum-version policy, devices drift. When the next actively exploited renderer bug lands a Stable patch, your exposure window is defined by your slowest device, not your fastest.

A Chrome Dev release is the right moment to check all three.

Executive Takeaways

1. Restrict corporate Android devices to Chrome Stable. Use your MDM/UEM (Android Enterprise managed Google Play) to approve only the Stable Chrome app for work profiles and fully managed devices. Chrome Dev, Beta, and Canary should not appear in the managed Play catalog.

2. Block sideloading and unknown-source installs. Enforce install_unknown_sources restrictions via Android Enterprise policy. Pre-release browsers that can't come through managed Play will come through APK sideloads unless you close that door.

3. Set a minimum browser version floor and enforce it. Define policy: devices must run Chrome Stable no older than N-1 milestone. Devices out of compliance should lose access to corporate resources via conditional access until remediated.

4. Don't forget Android System WebView. Track WebView patch level alongside Chrome. Include it in your mobile vulnerability scans and your monthly patch reporting.

5. Segment developer populations explicitly. If engineering teams genuinely need Chrome Dev for web platform testing, confine it to dedicated test devices or emulators without corporate credential access — never on the same profile that holds SSO sessions.

6. Use release announcements as audit triggers. Each Chrome milestone (Stable, Beta, Dev) is a scheduled, predictable prompt to reconcile your mobile app inventory against policy. Automate the diff; don't rely on memory.

Auditing Your Fleet: Installed Chrome Packages on Android

If you have ADB access to managed or test devices, you can enumerate exactly which Chromium-channel packages are present and what versions they're running. Chrome Dev installs as com.chrome.dev (Beta is com.chrome.beta, Canary com.chrome.canary, Stable is com.android.chrome).

# List all installed Chrome-channel packages on a connected device
adb shell pm list packages | grep -i chrome

# Pull version info for each Chrome variant found
for pkg in com.android.chrome com.chrome.beta com.chrome.dev com.chrome.canary; do
  ver=$(adb shell dumpsys package $pkg | grep -m1 versionName)
  echo "$pkg -> $ver"
done

# Check Android System WebView version (package: com.google.android.webview)
adb shell dumpsys package com.google.android.webview | grep -m1 versionName

# Verify unknown-sources installs are blocked (should return 0 / disabled on managed devices)
adb shell settings get secure install_non_market_apps

At scale, pull this same data through your MDM's app inventory report rather than per-device ADB — every major UEM (Intune, Workspace ONE, ManageEngine, Google endpoint management) exposes installed-package and version fields for enrolled Android devices. Build a saved query for com.chrome.dev, com.chrome.beta, com.chrome.canary, and any non-Google browser package outside your approved list, and alert on new matches.

Remediation Steps

1. Inventory today. Query your MDM for all Android devices with com.chrome.dev, com.chrome.beta, or com.chrome.canary installed. Any hit on a device with corporate data access is a policy violation to remediate, not a curiosity.

2. Remove and replace. Uninstall pre-release builds and install Chrome Stable (com.android.chrome) via managed Google Play. As of this writing, Chrome Stable is on the 14x milestone track; Dev 159 confirms the pipeline is already two milestones ahead — exactly the gap you don't want on production devices.

3. Enforce policy, not preference. Publish Chrome Stable as a required app in Android Enterprise and remove pre-release channels from the available catalog. Pair with unknown-source install restrictions.

4. Set conditional access floors. Configure compliance rules so that devices with unapproved browser packages or Chrome versions older than your N-1 floor are flagged non-compliant and blocked from corporate resources.

5. Verify WebView parity. Confirm Android System WebView is current on all enrolled devices and auto-updating through managed Play.

6. Track the upstream sources. Subscribe to the Chrome Releases blog (chromereleases.googleblog.com) and the Chromium blog so Stable-channel security releases — the ones that actually carry CVE fixes and occasional CISA KEV relevance — trigger your emergency patch process for mobile, just as they should for desktop.

None of this is glamorous. But browser channel discipline is one of the cheapest controls in mobile security, and a routine Dev-channel announcement like this one is the perfect low-stakes moment to verify yours is actually working — before the next Stable release arrives with a fix for something already being exploited.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub