您可以通过在用户代理中查找“Android”并检查 AppleWebKit/### 版本号来区分普通浏览器和 Chrome 浏览器。
库存的 Android 浏览器从未超过 534,而 Chrome 为 537 或更高。
var maybeAndroid = navigator.userAgent.indexOf('Android') >= 0;
var webkitVer = parseInt(/WebKit\/([0-9]+)|$/.exec(navigator.appVersion)[1], 10); // also matches AppleWebKit
var isAOSP = maybeAndroid && webkitVer <= 534 && navigator.vendor.indexOf('Google') == 0;
这是 99% 可靠的,并且对于使用 WebView 的 Android 4.x 上的应用程序非常有用。
==详细信息(如果您想深入了解!)==
编辑 7:'AudioNode' in window
可能是 AOSP(或旧 Chrome)与现代 Chrome 版本的安全嗅探。在这里试试。window.AudioNode 是作为 Chrome 29 中 WebAudio 支持的一部分引入的(并且不太可能被制造商向后移植)。我们的 4.0.3 手机上装有 Chrome 41,并'AudioNode' in window
返回true
Chrome 和false
AOSP。您还可以嗅探在 AOSP 完成开发后引入的其他功能——请参阅此链接以了解其他潜在的嗅探功能。选择 Chrome 42 之前引入的功能,因为 Android 4.0 用户无法升级到该版本。像往常一样使用 Android,肯定会出现奇怪的边缘情况,但这种嗅探可能与您所能获得的一样好(特别是如果结合检查 WebKit 版本 < 537)。
编辑 8:
==Android 上的 WebView==
在应用程序中使用 WebView 时,检查 <= 534 是一个完美的测试。Android 4.3(对 WebView 使用 AOSP 的最后一个 Android 版本)的兼容性定义表明,WebView 用户代理必须是:“ Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
”。
Android 4.4(第一个使用 Chromium for WebView 的 Android 版本)的兼容性定义说 WebView 用户代理必须是:“ Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
”。
小于 Android 4.3 的定义与 4.3 非常相似(总是 AOSP)。大于 4.4 与 4.4 的定义非常相似(总是 Chromium)。
==Android 上的 AOSP==
对于设备上的浏览器(不是 WebView),用户代理不受兼容性定义的限制。实际使用的浏览器版本差异很大,如quirksmode和三星浏览器版本所记录的那样。
编辑 4:推荐的解决方案是在用户代理中查找没有 Chrome 的 Android,如下所示:https ://developer.chrome.com/multidevice/user-agent#webview_user_agent但也可能需要确保不存在 /Windows Phone/ 因为 Mobile-IE11-8.1-Update 在 UA 中也有 Android " Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 520) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537
"。编辑 5:https ://msdn.microsoft.com/en-us/library/hh869301(v= vs.85).aspx 显示 Windows Phone 上的 IE12 仍将在用户代理中使用 Android。
编辑 3:正如评论者所说,有 AOSP 和 >= 535 的设备,但这是我发现的最可靠的测试(我希望看到更好的东西)。如果嗅探失败,您可以尝试确保您的代码仍然有效,并接受 Android 碎片意味着会有奇怪的设备失败。买者自负。编辑 6:查看特定站点的一些数据,大约 1% 的看起来是 AOSP 登录有 WebKit 537,所以虽然它看起来相当可靠,但它绝对不是 100% 可靠的。
编辑 2:如果您在应用程序中使用 WebView,则此检测对于 Android >= 4.0 && Android < 4.4.4 很有用,因为即使设备上安装了 Chrome,WebView 组件也会使用 AOSP。
编辑 1:由于原生 android 现在已经“过时”,因此对其进行测试是合理的(并使用该标志来解决使用特征检测无法检测到的差异)。