Develop Reference

does Oculus browser support WebRTC?

I can't seem to find anything definitive about whether WebRTC (or some subset of features) is supported in Oculus Browser 12.0, and I don't have access to one to test myself.
According to the Oculus Browser 12.0 release notes, it uses Chromium version 86. According to the WebRTC Wikipedia page, Chrome has supported WebRTC since 29. So that seems promising. But caniuse.com says that it's only supported in 87 (unless I'm reading that wrong...). It's unclear to me what the relationship is between Chrome, Chromium, and Chrome for Android. Just because it's "supported in Google Chrome", does that mean it's supported on all platforms? Are Chrome for Android and Oculus Browser basically same thing for the purpose of which APIs it supports?
Thanks in advance!

WebRTC does work in Oculus Browser.
I'm not sure why caniuse does not have data for Chrome for Android before 87. WebRTC was implemented in Chrome for Android in 2012 and shipped in 2013. Here's the old launch bug for WebRTC on Android in the Chromium bug tracker.
Google Chrome and Oculus Browser are different browsers, but they share a lot of code from Chromium. One browser supporting feature X does not guarantee that the other browser does, but it is usually the case.
If an API is not core to your experience, it is good to use feature detection and degrade gracefully if an API is not implemented on a browser you're on.

Is there a minimum Android version for supporting inappbrowser?

Our Phonegap app using inappbrowser works really well on every device tested except one using Android version 4.3 where the CSS seems unresponsive and the onscreen keyboard doesn't pop up when you tap in text fields. I can't seem to find any documentation on minimum versions of Android for supporting the various Phonegap plugins.

From my experience, I've used phonegap a far as Android 2.1 . The problem you could have on such older versions is the phonegap version.
You should provide further information such as phonegap version.
But I can assure you that Android 4.3 has a very broad support for all Phonegap/Cordova 5+ plugins.
If I were you I wolud try updating phonegap version according to your desire of minimum Android version you want your app to be executed on.
For example, until Android 2.3 on inappbrowser apps it wasn't able to use overflow scroll, so you had to use an external plugin to get that effect, which was really annoying.
Hope this helps.

Without any code it's hard to diagnose, but it might be a browser issue: Android 4.3 does not necessarily ship with Chrome, so it might be still running the old "Android Browser", which does not support all (CSS-)features Chrome supports. Caniuse helps to find out if a browser supports a certain feature.
If it's indeed a browser issue and you have to support older browsers like the Android Browser, you might want to check out Crosswalk. It provides a recent version of Chrome as a WebView and as InAppBrowser with consistent behaviour on all Android 4.x devices. Downside: Your app's size will increase...
If it's not the browser you might need to show us some of your code.

What is the engine of Android native browser?

What is the engine of Android native browser? Wiki says that Android used WebKit before 4.4 and Blink for 4.4 and further versions. Is it right statement? Thanks in advance.

The default browser on Android is Google Chrome. This uses the Blink layout engine. For AOSP installations without the Google Apps, the default browser is the old "Browser" app that uses Webkit.
other third party browsers like Firefox uses Gecko, Opera uses Blink, Dolphin uses Webkit, and there are probably others. Additionally, also Samsung and HTC install different (non-Chrome) browsers on their phones. I do not know what they are, or what engine they use.
similar question answered you can see here

I had a similar question. Below is what I found.
1. Wikipedia article
List of features in Android:
Web browser
The web browser available in Android is based on the open-source Blink (previously WebKit) layout engine, coupled with Chromium's V8 JavaScript engine. Then the WebKit-using Android Browser scored 100/100 on the Acid3 test on Android 4.0 ICS; the Blink-based browser currently has better standards support. The old web browser is variably known as 'Android Browser', 'AOSP browser', 'stock browser', 'native browser', and 'default browser' (from the time it was always the default). Starting with Android 4.4 KitKat, Google has begun licensing Google Chrome (a proprietary software) separately from Android, but usually bundled with (what most device vendors did). Since Android 5.0 Lollipop, the WebView browser that apps can use to display web content without leaving the app has been separated from the rest of the Android firmware in order to facilitate separate security updates by Google.
2. HTML5test's slides
The Android Browser
ANDROID 4 DEVICES
ALSO COMMONLY SHIP WITH
GOOGLE CHROME
DEPENDING ON YOUR DEVICE
GOOGLE CHROME COULD BE
AN EXTRA BROWSER
THE DEFAULT BROWSER
THE ONLY BROWSER
OR NOT THERE AT ALL
ANDROID 4.4 SHIPS
WITH A NEW WEBVIEW
BASED ON
CHROMIUM 30
BUT NOT THE SAME AS
GOOGLE CHROME
THE CHROMIUM BASED WEBVIEW
WILL BE UPDATED REGULARLY
ANDROID 4.4.3 → CHROMIUM 33
ANDROID 5 → CHROMIUM 37
IN FACT ON ANDROID 5
THE WEBVIEW CAN BE UPDATED
INDEPENTENTLY OF THE OS
3. Release Notes on WebView
Android 4.4 KitKat
Chromium WebView
Android 4.4 includes a completely new implementation of WebView that's based on Chromium. The new Chromium WebView gives you the latest in standards support, performance, and compatibility to build and display your web-based content.
Chromium WebView provides broad support for HTML5, CSS3, and JavaScript. It supports most of the HTML5 features available in Chrome for Android 30. It also brings an updated version of the JavaScript Engine (V8) that delivers dramatically improved JavaScript performance.
In addition, the new Chromium WebView supports remote debugging using Chrome DevTools. For example, you can use Chrome DevTools on your development machine to inspect, debug, and analyze your WebView content live on a mobile device.
The new Chromium WebView is included on all compatible devices running Android 4.4 and higher. You can take advantage of the new WebView right away, and with minimum modifications to existing apps and content. In most cases, your content will migrate to the new implementation seamlessly.
Android 5.0 Lollipop
Chromium WebView
The initial release for Android 5.0 includes a version of Chromium for WebView based on the Chromium M37 release, adding support for WebRTC, WebAudio, and WebGL.
Chromium M37 also includes native support for all of the Web Components specifications: Custom Elements, Shadow DOM, HTML Imports, and Templates. This means you can use Polymer and its material design elements in a WebView without needing polyfills.
Although WebView has been based on Chromium since Android 4.4, the Chromium layer is now updatable from Google Play.
As new versions of Chromium become available, users can update from Google Play to ensure they get the latest enhancements and bug fixes for WebView, providing the latest web APIs and bug fixes for apps using WebView on Android 5.0 and higher.
Android 7.0 Nougat
WebView
Chrome + WebView, Together
Starting with Chrome version 51 on Android 7.0 and above, the Chrome APK on your device is used to provide and render Android System WebViews. This approach improves memory usage on the device itself and also reduces the bandwidth required to keep WebView up to date (as the standalone WebView APK will no longer be updated as long as Chrome remains enabled).
You can choose your WebView provider by enabling Developer Options and selecting WebView implementation. You can use any compatible Chrome version (Dev, Beta or Stable) that is installed on your device or the standalone Webview APK to act as the WebView implementation.
Multiprocess
Starting with Chrome version 51 in Android 7.0, WebView will run web content in a separate sandboxed process when the developer option "Multiprocess WebView" is enabled.
...

Do mobile chrome apps run in chrome?

To put it bluntly, do Mobile Chrome Apps have anything to do with chrome at all? After all, it seems reasonable to expect that as it has Chrome in the name. This question stems from the fact that as I was porting my 'chrome based mobile app' (which does not run in the 'Browser'), I got a huge string of weird errors and for the first couple of hours I had no idea what was happening.
NOTE: This question is out of date, Mobile Chrome apps now works differently as outlined in the edit section of the main answer:
By default, Chrome Apps for Mobile leverage an embeddable Chromium WebView provided by the Crosswalk project by default, which has both advantages and some tradeoffs.

(Note: I work on the (very small) team at Google building the open source project to bring Chrome Apps to Mobile)
First, I’ll paste the description of Chrome Apps, right from the top of the docs:
“Chrome Apps deliver an experience as capable as a native app, but as safe as a web page. Just like web apps, Chrome Apps are written in HTML5, JavaScript, and CSS. But Chrome Apps look and behave like native apps, and they have native-like capabilities that are much more powerful than those available to web apps.
Chrome Apps have access to Chrome APIs and services not available to traditional web sites. You can build powerful apps that interact with network and hardware devices, media tools, and much more.”
Next, I’ll paste the description of Chrome Apps for Mobile, right from the top of our README.md:
“You can run your Chrome Apps on Android and iOS via a toolchain based on Apache Cordova, an open source mobile development framework for building mobile apps with native capabilities using HTML, CSS and JavaScript.
Apache Cordova wraps your application's web code with a native application shell and allows you to distribute your hybrid web app via Google Play and/or the Apple App Store. To use Apache Cordova with an existing Chrome App, you use the cca (c ordova c hrome a pp) command-line tool.”
Now to answer your question: “To put it bluntly, do Mobile Chrome Apps have anything to do with chrome at all? After all, it seems reasonable to expect that as it has Chrome in the name.”
Blunt Answer:
No, they don’t run on Chrome in the same sense that they do on desktop. However, using cca they can run on Mobile in ways that are most appropriate for those platforms, and we do use the Chrome Renderer whenever/however we can.
EDIT as of July 2014: We now run apps inside the Crosswalk WebView on every version of Android (currently based on Chrome 36, but that will change with time). I described this approach at the bottom of this original answer, but some of the details about system webviews -- while still accurate -- no longer really apply to Chrome Apps for Mobile. You can read more about this on our main github page.
Sorry for the naming confusion. I do see why it is reasonable to assume what you did. The “Chrome” in “Chrome Apps for Mobile” refers specifically to the source application type, not to the target runtime type. We try to document that best we can -- Do you have a suggestion for a simple yet less confusing title?
Less-Blunt Answer:
Chrome Apps for Mobile is an open source project to build a tool to support wrapping existing Chrome Apps into Hybrid Mobile Apps, leveraging Apache Cordova.
That is, cca creates a 100% real Android/iOS app, like any other, built using the respective Mobile SDK. Additionally, for your benefit and convenience, we create an app shell that uses the system WebView component to display and run your application content. We read your application manifest, we simulate the Chrome App lifecycle, we run your background scripts, open chrome app windows, and implement many of the Chrome Apps device apis. We’ve bundled all this work up into one toolkit which we call cca. We also contribute a lot of patches to core cordova to generally make all hybrid apps on Android/iOS better.
Now, the default system WebView’s are as follows:
iOS: Mobile Safari WebKit based. Lots of web-platform overlap with Chrome, but not exact and diverging slowly.
Android 4.3 or older: Legacy Android WebView. Dated and occasionally buggy, but still fairly performant on certain tasks.
Android 4.4: Chrome based WebView. This initial release brought a slew of modern web apis, and enabled remote web inspector. However, it also introduced some regressions, is stuck at Chrome 30, and didn't bring all features, such as WebGL and WebRTC.
Android Future: Since the first launch of Chrome based WebView, it was announced that work is ongoing to make the WebView auto-update just like the Chrome Browser does.
So, on Android 4.4 we already use a real Chromium renderer to turn your Chrome App into pixels on screen. On iOS, the WebView is quite modern and performant and many apps should run fine. For Android Legacy WebView, its hit and miss. But there is hope...
Excitingly, a significant portion of our recent work on cordova-android has been on bundling a tip-of-tree chromium based “webview” alongside your app, thanks to the Intel Crosswalk project. This would mean you ship your app to the Play Store together with your very own modern build of Chromium webview. Best yet, it will work all the way back to Android 4.0. Expect announcements on how to try it yourself in the next month or so!
Finally, while there are some downsides, it's important to note the benefits of our approach:
By running as a real Android/iOS hybrid app, you can write your own cordova plugins to run native Android/iOS code to augment your application should you find the need to do so.
Your app distributes using the app store, with user reviews, auto-updates, and monetization.
Your app has an icon on the users' home screen, and is in the app switcher, etc.
Most importantly: You don't have to wait for the future! Get started today using cca, and run your Chrome Apps on iOS and Android using the webviews currently available, and soon to be improved.

NO on android 4.3-, Mobile chrome apps run in the standard Browser, not in Chrome. The chrome part in the name can be considered either a lie or just referring to the part that it supports a few API's that are supported by real Chrome Apps as well.
Yes, but NO on android 4.4+, as the standard android.webkit.WebView has been updated to Chrome 30, but will at least for the moment NOT get the same updates as Chrome and thus end up in the same situation as now where Chrome will run applications differently from the android.webkit.WebView again. Technically the answer is still yes to the question: 'Does it run in chrome', but for all practical means the answer is a clear no (as we're at version 34-36 already now).
This can be found out by either investigating the User Agent or checking for specific support for certain functions. For the user agent mobile chrome apps will return something along the lines of
Mozilla/5.0 (Linux; U; Android 4.2.2; en-gb; ZP998 Build/JDQ39) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
And chrome will return
Mozilla/5.0 (Linux; Android 4.2.2; ZP998 Build/JDQ39) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.114 Mobile Safari/537.36
And the browser
Mozilla/5.0 (Linux; U; Android 4.2.2; en-gb; ZP998 Build/JDQ39) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
The expected behaviour of the mobile Chrome apps should have been that the Chrome browser itself would expose an API which they would have used, but instead they really did nothing more than fork cordova and be done with it. On iOS this would have made sense, as that's how the 'Chrome' browser works there as well, but in both cases it should run the same code as Chrome which at the moment of speaking it does not.

The Chrome Apps platform defines a set of APIs and a runtime model to make it easy to use web technology to write apps that have native capabilities. You write an app that runs on that platform, and we (the Chrome team at Google) implement the platform on different host architectures. It's "Chrome" in the sense that the Chrome browser, Chromecast, ChromeOS, and Chromebooks are all under the Chrome brand. Chrome does not necessarily mean Chrome web browser.
Yes, on desktop, the Chrome browser happens to be the same executable that implements the Chrome Apps runtime. But to the greatest extent possible, we try to make that just a detail of implementation. A user can use Firefox or Internet Explorer as their default web browser, and never use the Chrome browser, but still use Chrome Apps.
As David Mulder says, Cordova apps (Mobile Chrome Apps) don't use the Chrome browser as their runtime on either iOS or Android. Each Cordova app is its own executable. But where possible, they'll use the Chrome Webview component, so that the inevitable compatibility nits among different webviews are minimized for a given Chrome App.

Mulder's answer makes no sense to me, and I have no idea what he means when it refers to the user agent. What Cordova does for Chrome Apps is provide the same Chrome App APIs (not all are implemented yet) on Android and iOS, but the resulting app is a native Android or iOS app, which has nothing whatsoever to do with any browser, just as all other Android or iOS apps do not.
In short, the answer is "no."
(The technology does not allow a Chrome App to run on Andoid or iOS. Rather, given the source code of that app, you can build it for those platforms, resulting in a new binary, native app.)

Will Android support WebSockets in an upcoming version?

If so, does anybody know which version it's scheduled to be supported in (in built-in Chrome Lite browser)? Also, is it currently supported on any of the alternative browsers for Android like FireFox or Opera Mini?

Will Android support WebSockets in an upcoming version?
Probably, given Google's HTML5 emphasis.
If so, does anybody know which version it's scheduled to be supported in (in built-in Chrome Lite browser)?
Google does not publish that sort of detail in advance of releases. Hence, you'll know about it when it ships, not sooner.
Also, is it currently supported on any of the alternative browsers for Android like FireFox or Opera Mini?
Firefox Mobile's FAQ does not list it among the HTML5 features it presently supports. I have no idea about other browsers.

The iOS 4.2 beta currently has WebSockets support: http://twitpic.com/2yiygv
Come November when iOS 4.2 actually ships, if it still has WebSockets turned on (it has been in a previous beta and been turned off before shipping), then you can be sure that google won't be far behind.
Regardless, I predict that it will arrive with Gingerbread (the next one) since they are making such as big for other HTML5 features in that version: http://www.shoutpedia.com/what-is-next-to-froyo-android-2-3-might-be-released-by-fall-of-2010-3457/

Opera Mobile, Opera Mini and Firefox Mobile do not currently (Feb 2010) support WebSockets and won't do so until a change to the specification has been made. This is because a security issue was found in November 2010 in the underlying protocol: http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html
I imagine WebKit support is also on hold until it's safe again, but it's not clear when that will be.

It's 2012, and the Android Browser still doesn't support Websockets (at Android v4.0). Also, there does not seem to be any indication into have websocket in the Android Browser. some speculation seems to revolve around Google switching the Android Browser with Chrome for Android (why they didn't do this before, is beyond me).
iOS (safari, chrome and opera*) has been supporting Websockets for some time now, however, you loose iPhone 3 (and below) clients. Not that they're much nowadays (from statistics).
Flash....well, flash isn't a browser platform, but it's a good fallback. Thanks to Flash, you can get websocket goodness on older browsers like IE, even on Windows Mobile.
Still, it doesn't fix the issue on Android (the default flash player is a slim vendor-specific mutilation) nor does it work for older iPhone/iPad versions (they tend to get sick whenever they hear anything about flash).
*Opera Mini DOES NOT support websockets, as opposed to Opera Mobile.

Even BlackBerry 6.1+ supports Websockets, but not Android. Google was first in HTML5 among desktop browsers and seemingly last one among mobile platforms.

The iOS WebKit does only support old, outdated WS spec. Not RFC6455.
On Android: built-in browser up to and incl. Android 4: no WS support whatsoever.
Firefox Mobile .. current WS spec support. Same with Chrome for Android (only avail. for Ice Cream).
===
Btw: For Android native apps, there is Autobahn WebSockets for Android
https://github.com/oberstet/AutobahnAndroid
It supports the final RFC6455, integrates well with UI and service apps, provides RPC and PubSub over WebSockets, and more. Check out the project README on GitHub.
Disclaimer: I am the author of Autobahn.

Firefox Mobile 7(Aurora) support WebSocket(renamed to MozWebSocket):
console.log(window.MozWebSocket.prototype)