Webview set user agent android

WebView for Android

Published on Friday, February 28, 2014

Since Android 4.4 (KitKat), the WebView component is based on the Chromium open source project. WebViews now include an updated version of the V8 JavaScript engine and support for modern web standards previously missing in old WebViews. New Webviews also share the same rendering engine as Chrome for Android, so rendering should be much more consistent between the WebView and Chrome.

In Android 5.0 (Lollipop), the WebView has moved to an APK so it can be updated seperately to the Android platform. To see what version of Chrome is currently used on a Lollipop device, simply go to Settings XMLHttpRequest s made from JavaScript. Those requests always use the default user-agent string.

# Does this mean Chrome for Android is using the WebView?

No, Chrome for Android is separate from WebView. They’re both based on the same code, including a common JavaScript engine and rendering engine.

# Does the new WebView have feature parity with Chrome for Android?

For the most part, features that work in Chrome for Android should work in the new WebView.

Chrome for Android supports a few features which aren’t enabled in the WebView, including:

Feature	WebView v30	WebView v33	WebView v36
WebGL	x	x	✓
WebRTC	x	x	✓
WebAudio	x	x	✓
Fullscreen API	x	x	x
Form validation	x	✓	✓
Filesystem API	x	x	x
File input type	x	x	x
x	✓	✓

# What hardware sensor APIs are available to the new WebView?

Some HTML5 APIs can be used to access the hardware sensors on an Android device. Chrome for Android supports a few of these APIs but not all of them are currently enabled in the WebView.

API	WebView v30	WebView v33
Geolocation API (requires android.permission.ACCESS_COARSE_LOCATION and/or android.permission.ACCESS_FINE_LOCATION permissions)	✓	✓
Device Orientation API	x	x
Media Capture and Streams	x	x
Vibration API (requires android.permission.VIBRATE permission)	x	✓

# What does the new WebView mean for developers?

This is a big change from the original WebView as it brings a new set of HTML5 feature support, improved JavaScript performance, and remote debugging of web content using the Chrome DevTools.

There are some changes that will affect existing apps.

If you are currently using content:// URLs to load files from a content provider in your application, note that these URLs only work when accessed from local content. That is, web content hosted outside your application is not allowed to access files built into your application.

There are a small number of other changes that might impact your application. Read the migration guide for more information.

# How do I enable remote debugging?

# Does the WebView support the Chrome Apps APIs?

No. The Chrome Apps platform isn’t yet supported on Android.

# Should I enable hardware acceleration?

Hardware acceleration is enabled by default. If you are explicitly disabling it for older versions of Android you should try enabling it for KitKat based devices and see if it improves performance.

Last updated: Friday, February 28, 2014 • Improve article

Источник

Correctly Form User-Agents for Webview Apps

Nov 15th, 2017

Hybrid webview apps are a popular and cost efficient way to distribute online properties through app stores. A hybrid app is a native application with all the bells and whistles, but some part and sometimes even all functionality is developed using HTML, CSS, and JavaScript and rendered by a webview component. This is why the hybrid app is also called a “webview app”. You can think of the webview component inside the app as a browser window. Inside the browser window, a webpage or web app is rendered. This page or app is communicating with a server on the internet, just like a web browser. We know how important the User-Agent string is for device detection in web browsing, and correctly formed User-Agents for Webview Apps is just as important for effective browsing, analytics, and targeting.

This article will teach you how to steer away from the generic defaults and correctly form a meaningful User-Agent for hybrid webview apps on mobile devices running the most popular platforms. If your app does not use webviews, then please read this post to learn how to structure User-Agents for native mobile apps .

Importance of User-Agents for Webview Apps

The User-Agent is a header field in the HTTP request. Its purpose is to identify the the program or application making a request for web content. The User-Agent “ is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use ”, according to the specification .

In a hybrid webview app context, enabling the webpage or app displayed inside the webview to adapt navigation or presentation to the different browsing experience is very useful. Especially when the webpage integrates with functionality natively built into the hybrid app.

From an analytics perspective, it is crucial to know where the traffic of the hybrid app is coming from and which app versions on which devices are generating the traffic. This is not obvious using the defaults provided by the SDK.

The motivation for meaningful User-Agents in hybrid apps is much the same as for native apps , but with User-Agents in hybrid apps they carry app information, device information, plus the standard browser information.

Adding information to the User-Agent in hybrid apps is already common. Most of the popular apps like Facebook, Twitter, and Instagram already do follow these User-Agent guidelines.

Composing the User-Agent for Webview Apps

How should the User-Agent be formed? In the following we’ll demonstrate how to compose the User-Agent for webview based applications. The base of the User-Agent is the default User-Agent as provided by the platforms SDK, and then app and device information is appended. This is the defacto standard as it has developed in the wild:

Note the WebViewApp identifier before the app name and version.

Let’s look at how to compose the correct User-Agent for different platforms and operating systems. For this purpose, we’ll construct User-Agents for a webview app called Foo, version 1.

User-Agent for Hybrid Android apps

For our app running on a Google Pixel, this is how our User-Agent could look:

The code to construct the User-Agent is:

User-Agent for Hybrid iOS Apps

For iOS it is slightly more complicated, but still not difficult. We still want to append app name and version, but in addition we want to append the specific iPhone model at the end:

Above is the User-Agent of Foo version 1 running on an iPhone iPhone XR (iPhone11,8).

The examples below use the deviceName() to get the model information. See github for full code examples .

Objective C

In Objective C, we retrieve the user-agent by creating a webview:

Then we modify the extracted User-Agent via the AppDelegate file:

Swift

In Swift we do it like this:

Windows Phone

Like for Android, we only need to append the app name and version since the device info is already in the default User-Agent.

First we extract the User-Agent by creating a webview:

Now, append “ WebViewApp Foo/1”.

Then have the webview use your custom User-Agent:

The Foo/1 app on a Lumia could look like this:

Conclusion

With this relatively modest effort during development, you can gain better analytics of your apps usage patterns and adapt content and ads to their specific apps, devices, or OS.

Источник

How to Set Custom User Agent in Android WebView

Set Custom User Agent Android WebView

Updated on: June 29, 2021

In webview of Android, if you want to set custom user agent,this tutorial is for you.

Custom user agent can be helpful if some options of a website is only available in the desktop version of the site – not on mobile version, or you just want your app to have the option to change user agent, etc

To set a custom user agent, we need define the user agent in a string, then pass the string to setUserAgentString(your string name here).

Create a new string

In the activity of the webview, create a new string,

So we created a string for user agent, the user agent defined in the string is of a desktop browser user agent, with this user agent set – your Android browser will load desktop version of websites. You can change this user agent to other user agents you like.

So we set the string, now let’s call it

Here we called the string that we have set, it is ready now.

This code can be inside the oncreate method of the web activity.

Meet Advanced Plus

I highly recommend you use the new and advanced Android Webview Advanced Plus Source Code we developed to easily convert any website to android app. No coding required, just set your website link, app color, icon etc and the app will be ready!, and it supports upload, download, loading progress bars, notification, night mode etc. To learn more about the Android Advanced Webview Source Code and to download it, head over to this page Download Android Webview Source Code

Источник

Webviews and User-Agent strings

Much is made of the comparative times spent browsing the web vs engaging with native apps in the apps vs web debate. An often overlooked part of the discussion is that when engaged with a native app some portion of this time is spent actually on the web, via a webview. We’ll get to what a webview is in a minute, but for now, what this means is that although the user is in an app, he or she is effectively browsing the web. Apart from skewing the numbers, or at least muddying them a little, in the app vs web debate, there are some consequences of this for developers and publishers to consider:

• the numbers of web visitors coming via webviews is likely to be significant when we consider popular apps like Facebook and Twitter, and the ease with which links are shared in these apps
• web developers should be considering webviews testing in their release cycle
• app publishers should be applying responsible user-agent adoption practices, or traffic from their apps won’t be identifiable or targetable

In the following sections, we cover what a webview is, how they can be detected, and since, as we’ll see, webview User-Agent strings are a bit of a mess right now, we make some recommendations about how to clean them up!

What is a webview?

A webview is pretty much a browser wrapped inside of an app. Let’s say you’re in Facebook, and a link is shared with you; you tap the link, and instead of switching you over to your browser, Facebook opens the link instead for you. What’s happening is that Facebook is making use of the phone’s webview component to open the link. It is basically the rendering component of the browser, without the UI. Apps such as Facebook like this functionality as it allows the user to view the link without ever leaving the app, and gives the app further user-behaviour signals for user profiling, and of course app authors don’t want users to leave their apps; they might never come back!

Whether or not this is the best experience for the user is up for debate. Some would argue that it makes the experience more seamless. Others would argue that it locks the user into a silo, and costs the user the use of his or her bookmarks, tabbed browsing, and all the other benefits to having control of his or her own browser.

Webview (left) and Chrome browser (right), on Android

The images above show a couple of things. The first shows google.com loaded via Facebook webview, and the second via Chrome browser, both on Android.

This first notable difference is in the UI: Chrome shows the full URL, while Facebook webview shows the page title. This is not too much of a big deal, although it does make changing URL impossible.

Note that the content is different too. Chrome is personalised with all my preferences and cookies. So when I visit a site I’ve been to before, say, one that I’m logged into for example, its state is restored; I don’t need to log in again—I can pick up where I left off. This is why we see personalised content in the Chrome image above. While the webview will handle and retain cookies across sessions, unless you log in again in the webview, you won’t be logged in! And if you do login in on the webview, it’s a different session than the one on your native browser. And, while we’re talking about cookies, we should probably mention you’ve no control over them in the webview anyway!

Webview menu (left) vs browser menu (right)

Now take a look at the second pair of images, this time showing the respective menus of the webview and native browser. The main thing to notice is the difference in control you have. In the native browser you have access to your bookmarks, browsing history, text search and more. In the webview you have access to sharing options, and that’s it. A app purist might argue that this makes the app experience better—you get to see the shared URL and that’s it, everything else is a distraction. But that’s a hard sell. For one thing, wouldn’t it be nice if you could keep track of the sites you visited, just like in the native browser? You can be sure that apps like Facebook are doing just this with links opened in the webview.

Forcing users to use webviews also denies other full-fledged browser benefits. For instance, if you are bandwidth-challenged you might prefer to use the bandwidth-saving page-shrinking features of Opera Mini, or Opera’s Turbo mode. Or if you are privacy-conscious (and you should be!) you might want to disable third-party cookies. These things aren’t possible with today’s webviews.

Detecting webviews

When requesting pages, webviews send User-Agent headers, just like regular browsers. The User-Agent string can be changed by the app. This is important, because it means we can differentiate between the webview traffic and browser traffic, and between the webview traffic from different apps. And this in turn means that we can tell, for example, that a certain portion of traffic came via the Twitter webview, and some other portion came with Facebook webview. Without the ability to change the webview User-Agent string, it would be a lot harder to differentiate webview traffic.

Changing the User-Agent string of a webview is simple. In an Android app for example, you would change it with a line of code something like this:

Источник