I came across this Android WebView function WebSettings.setDomStorageEnabled(true) and from the name alone I can infer that it simply "enables DOM storage".
The Android documentation, however, suggests something slightly different:
Set whether the DOM storage API is
enabled.
IOW, it enables the API rather than the storage itself.
My problem is... I didn't know about the existence of such an API until I encountered this function.
My Google search suggests that this API is closely associated with HTML5.
Does that mean that this function is
irrelevant to web sites/pages that
do not use HTML5? IOW, does it
affect existing non-HTML5 page
loading & rendering at all?
Where can I learn more about the DOM
storage API?
In particular, are there any gotchas
or caveats that I need to watch for
when calling
WebSettings.setDomStorageEnabled(true)
in an Android app?
Why is it disabled by default?
Update: I now can at least answer question #2: It turns out that the common name for "DOM Storage" is "Web Storage" and there is an entire Wikipedia article about this: http://en.wikipedia.org/wiki/Web_Storage
I believe this functionality is irrelevant for websites that do not use the HTML 5 specifications, since it is part of that spec. I would imagine the main thing to look out for when enabling this API is that it would then allow ANY website that takes advantage of DOM storage to use said storage options on the device. I would imagine it is disabled by default for space savings and security.
No. You will have to use it to enable some features of JS functionality as well.
devloper.android link:
http://developer.android.com/reference/android/webkit/WebSettings.html#setDomStorageEnabled%28boolean%29/
MDN explnation about DOM storage:
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage
You need to know there are security attacks that can be made (if you use it with js).
It opens some security vulnerabilities of the system.
Related
I have been looking at this blog https://nelenkov.blogspot.com/2012/08/accessing-embedded-secure-element-in.html, this is really good however I am having trouble understanding how to add the com.android.nfc_extras to my project. Also, the way the etc/nfc_access.xml file works.
If there is anyone that will help me break through this process then it will be nice, since I am new to this.
It really depends.
The most basic answer is: disregard the article (it's 6 years old, Android changed a lot!) and try to use GlobalPlatform Open Mobile API. It is API for accessing secure elements present on many phones.
Expanded answer: it varies between manufacturers. Some will allow you to access their embedded secure element (eSE) via OMAPI, sometimes you might need to use propietary service as a proxy. One example of vendor-specific service is Samsung KMS Agent (still, eSE is visible in OMAPI).
After that introduction, if you want to access eSE and you are new to this, you probably want to use OMAPI. If you are writing app targeting Android P - great news, OMAPI is now part of Android.
But in reality you would probably target older Android version, so bad news is - you don't know if OMAPI is present on the phone. See: List of OMAPI supported devices
But assuming you have OMAPI present, then take a look at Android documentation for OMAPI: https://developer.android.com/reference/android/se/omapi/package-summary and GlobalPlatform.org documentation e.g. OMAPI docs
I want to play widevine drm content in webview android using html5 code.
I tried a lot not succeeded, does widevine not supported in webview?
please give a way to play widevine in webview android and let me know if widevine does not support in widevine and why?
Any help and suggestion would be appreciated.
Unfortunately, the webview shipped with Android devices differs between devices and between Android versions.
There is an excellent overview here:
http://slides.com/html5test/the-android-browser#/42
You can test whether your device supports it by using an open source HTML5 player like Shaka in your webview and trying some of their demo content.
Shakaplayer includes a basic tutorial showing how to include the player in a webpage:
https://shaka-player-demo.appspot.com/docs/api/tutorial-basic-usage.html
You can also use a test app like the HTML5test Webview app - checking the streaming section to make sure MSE and DRM are both ticked:
https://play.google.com/store/apps/details?id=com.html5test.webview&hl=en
Widevine is supported on Android WebView. The following test page, can be loaded on the WebView to confirm that.
There is a drm key in the response:
"drm": {
"com.widevine.alpha": {
"persistentState": false
}
}
However, to ensure that Widevine is properly activated you need to make sure that you are loading the content within a secure context. You can read about secure contexts here. Quoting:
A secure context is a Window or Worker for which certain minimum standards of authentication and confidentiality are met. Many Web APIs and features are accessible only in a secure context. The primary goal of secure contexts is to prevent MITM attackers from accessing powerful APIs that could further compromise the victim of an attack.
In particular, don't use the loadData method as that wouldn't give you a secure context. Quoting the relevant part of the documentation:
Content loaded using this method will have a window.origin value of "null". This must not be considered to be a trusted origin by the application or by any JavaScript code running inside the WebView (for example, event sources in DOM event handlers or web messages), because malicious content can also create frames with a null origin. If you need to identify the main frame's origin in a trustworthy way, you should use loadDataWithBaseURL() with a valid HTTP or HTTPS base URL to set the origin.
Instead it is recommended to use loadDataWithBaseURL().
Finally, note that Widevine comes with 3 different levels of certification (L1, L2 and L3). L1 being the highest, using the Trusted Execution Environment. AFAIK, L1 may still not be supported yet
on WebViews as shown by this code review comment:
Unless there's some other hidden magic, I believe so. We'll enable L1 on WebView when AndroidOverlay is supported on WebView.
Note that this comment dates from 2017, so not sure whether it is still relevant. The point is that another reason why this wouldn't work is if decrypting the code requires L1 level and either your device or the WebView don't support it.
Hope that helps.
I have a very simple HTML5 app written with trigger.io that fails running under Android 4.4 with errors stating that local content cannot be accessed. Example:
E/AndroidProtocolHandler( 2236): Unable to open content URL: content:////io.trigger.forge9aee7db8338b11e4b77d1231392b77b0/src/images/connect4.jpg
The same code works find under Android 4.3. This applies to all local content including images, CSS and JavaScript. All resources are referenced with relative paths such as "images/image.jpg".
My best guess is that there is an access policy change in newer versions of Android OS but I cannot figure out the details. I have made sure that nowhere in the code attempts to access external resources.
Antoine van Gelder was incredibly helpful on this. His diagnosis was absolutely correct that jQuery Mobile is rewriting the URLs for resources which causes newer versions of Android's Chrome Webview to fail when accessing resources. The generated URLs contain quadruple slashes after the protocol like this:
content:////io.trigger.forge9aee7db8338b11e4b77d1231392b77b0/src/resource.png
The extra slashes cause Webview to fail. Possibly some excessive checking for correctness or a security implication?
Antoine's suggestions of using older versions of jQuery Mobile or building a custom jQuery Mobile without Base Tag will probably work in some circumstances though neither was quite sufficient in my case. Particularly, removing Base Tag also removes some other functionality I needed.
An alternative approach is to make a minor hack to jQuery Mobile. For version 1.4.3 I did the following:
Edited an un-minified version of jQuery Mobile's javascript
Modified the getLocation function:
Save the return value to a temporary variable
Modify the temporary variable by removing quadruple slashes.
I used something very specific and restricted to the "content" protocol: "retVal = retVal.replace("content:////","content://");"
Return the fixed temporary variable
It looks like, starting with v1.3, jQuery Mobile are rewriting the URL's in your document which breaks the Chrome Webview's access to files in the app sandbox.
You could try filing a bug report with the jQuery Mobile devs but to sort this out in the short term your best options are probably one of:
1) Fall back to jQuery Mobile 1.2.1
2) Build a custom version of jQuery Mobile which excludes some navigation features. (Go to download builder (http://jquerymobile.com/download-builder/), scroll down to "Navigation" and de-select the "Base Tag" module)
This should be fixed in JqueryMobile 1.4.4.
I noticed that a DropBoxManager has been introduced in Android API since FroYo (API 8).
It looks like an alternative logger capable of logging not only text but also files or byte arrays, but I could not find any detailed doc anywhere about how and when we should use it.
The latest android dev blog post introducing StrictMode talks about it, StrictMode can append data to the DropBox, and we are given a shell command to retrieve these data.
Please share here your knowledge about this! Why has it been implemented in addition to the usual logcat? Can we use this to share data across apps? What kind of apps use it?
There are basically three logs on the system:
Log:
for short, textual data
in-memory ringbuffer, fast
ephemeral (you'll lose it on a crash, or the ringbuffer scrolls)
intended for app developers
EventLog is:
for short, binary data
in-memory ringbuffer, fast
ephemeral (you'll lose it on a crash, or the ringbuffer scrolls)
intended for platform developers to collect statistics
DropBox:
for long text or binary data
persistent, written to disk
kinda slow (disk)
meant for platform developers too, mostly to collect crashes & large statistics
subject to limits, deleted by tag if a tag's count and/or size get too large
DropBox is what we used during development to capture all the StrictMode violations in Gingerbread.
You can use DropBox for one-off debugging, but it's not really recommended. It's definitely not recommended as a way to share data between apps. It's not reliable enough, and you can't put permissions on the data. You should just use a shared userid and use the normal filesystem with appropriate permissions.
What are the key differences between Android, iOS and Blackberry OS in terms of level of accessibility by application developers (i.e. access to the video input, sound input, phone functionalities, to which extent, etc.)?
PS: Assume latest version of each OS.
EDIT: Can someone turn this into a wiki so we can compile answers from people that don"t necessarily have experience in all 3 plaforms.
I'm not familiar with BlackBerry, but on Android and iOS you can access just about anything. Until recently iOS had some restrictions about camera access (see this), but I belive those have been solved. Because Android is open-source, you can theoretically go as deep as you want as far as accessing the hardware, but you may or may not be able to get any deeper through the standard Android API than you can through the iOS API.
On Android, you can do a lot more to override default functionality. For example, you can create your own launcher screen or phone application. The iOS approval process wouldn't allow these kinds of applications.
API hardware access really isn't an issue on either platform, the bigger concern is overriding default software (almost never possible in iOS) and what types of applications iOS allows.
Each platform has its own nice and bad parts. I have been working on both Android and BB. I wish I could take only nice parts from both to create a platform of a dev dream! :)
For instance, I could take these features from BB:
The greates feature I like in BB is the simplicity of the application architecture - you can always count on your main UIApplication instance - OS never kills it.
Also I do like the simplicity the Dialog class provides - it is very easy to implement business logic related to user choice - while Dialog screen is shown the code execution just stops and waits for user input.
From Android I'd take the following:
Network communication. On BB this is a real nightmare (BES, BIS, WIFI, Direct TCP without APN, Direct TCP with APN, WAP, WAP2, Unite - who's next? :)).
For file manipulations you just use a native/usual Java API.
Nice looking UI components are available right out of the box.
I should add I'm not happy with GPS related stuff on both platforms, however maybe it is due to GPS hardware limitations rather than API creators.
Thanks!
BlackBerry is a pain, once I made a project for it (the JDE version was 4.7 back then) and it didn't had an ArrayList. WTF?