What is PackageManager.FEATURE_WEBVIEW for? - android

My app uses WebView. As of L-preview, there is a new feature filter introduced:
FEATURE_WEBVIEW. Declares that your app must only be installed on devices that fully implement the android.webkit.* APIs. Example:
<uses-feature android:name="android.software.webview" android:required="true" />
Source: http://developer.android.com/preview/api-overview.html#Manifest
I would like to understand the impact and the reason of this feature filter.
Which devices won't implement full android.webkit.* API?
If I add this line into my AndroidManifest.xml, I expect my app will still be available for Android 2.3-4.4. Is that true?

Which devices won't implement full android.webkit.* API?
Android Wear, and perhaps others.
If I add this line into my AndroidManifest.xml, I expect my app will still be available for Android 2.3-4.4. Is that true?
It should be.

Related

How to set System Feature programatically on Android

I am implementing an application that transmits private TV broadcasting by referring to AOSP.
By default in AOSP, it says
"Enable the feature PackageManager.FEATURE_LIVE_TV".
I assumed this would be set by editing the manifest
<uses-feature
android:name="android.software.live_tv"
android:required="true" />
But this doesn't work,
getContext().getPackageManager().hasSystemFeature(PackageManager.FEATURE_LIVE_TV)
this returns false
(I made sure that getContext is never null!)
First of all, since there is no part to set Feature Flag among Developer Options in my device, I try to solve it programmatically.
Please tell me how to set software feature

Steps to programmatically cast from android to miracast receiver

I'm trying to write an app that will start casting the screen from an Android phone to a TV via miracast. I'm using an HDMI dongle since the TV in question doesn't natively support miracast. I have been trying the code here, but it needs an Application ID which I have got following these steps. My question is, the instructions seem to indicate that I need to register the miracast dongle so it will talk to an unpublished 'debug' app. However, only Google Cast devices are mentioned and that isn't the same protocol as miracast. Do I still need to register the dongle?
Is there a simpler way of programmatically casting to a device via miracast? A requirement is no user interaction, so I can't just display a cast button.
I'm using Android 5.1 if that's relevant.
EDIT: After further research, I realized that Google Cast uses a completely different protocol from Miracast, and thus all the talk of registering the dongle is irrelevant. No registration is required at all to do Miracast in Android. The issue is the API is hidden, see my answer below for details.
So this is possible, but only on custom versions of Android due to permission problems.
What you need to use
The hidden part of the WifiDisplay API makes it all possible. This file contains examples of how to use the API to cast the display. It appears that Google will release it publicly at some point, although it's still hidden in the latest master of API 23 as far as I can see.
How to access the hidden API
To use hidden APIs, this guide(mirror here) provides a good introduction. If you're using API 22+ however, then that guide won't work as the format of android.jar has changed and classes.dex has been split across multiple files. So this advice is more accurate in that case. Note that the postscript about framework-classes2.dex must also be done; it isn't optional.
The latest version of the dex2jar tool fails to turn the .dex file from API 22 into a jar. The solution is mentioned by the author here. I opted to patch the tool instead of changing the dex, as that didn't work for me. Simply change the line the author mentions from throwing a RuntimeException to:
return TypeClass.INT;
How to get permission to use the hidden API
Once that is all done, the next step is giving your app the CONFIGURE_WIFI_DISPLAY permission. Unfortunately, as you can see here, it has system-level protection. This means that your app must be signed by the same key as the system to use this permission. So unless you have Google's private key, you can't have your app run on normal Android phones. My solution was to build a custom version of CyanogenMod(using this guide), with the permission changed from 'system' to 'normal'. This eliminates the need to bother with signing anything. I also did the same for the CONTROL_WIFI_DISPLAY permission. Whilst I'm not entirely sure this is necessary, it doesn't hurt. Both these permissions are located in frameworks/base/core/res/AndroidManifest.xml. Change the lines 2161-2169 from:
<permission android:name="android.permission.CONFIGURE_WIFI_DISPLAY"
android:protectionLevel="signature" />
<permission android:name="android.permission.CONTROL_WIFI_DISPLAY"
android:protectionLevel="signature" />
To:
<permission android:name="android.permission.CONFIGURE_WIFI_DISPLAY"
android:protectionLevel="normal" />
<permission android:name="android.permission.CONTROL_WIFI_DISPLAY"
android:protectionLevel="normal" />
Then build CyanogenMod as normal. I can confirm this does work, but this limits your app to running on devices which have this custom version of CyanogenMod installed. Furthermore, installing CyanogenMod on an Android phone will generally invalidate the warranty.
try {
startActivity(new Intent("android.settings.CAST_SETTINGS"));
return;
} catch (Exception exception1) {
Toast.makeText(getApplicationContext(), "Device not supported", Toast.LENGTH_LONG).show();
}
hope this will help you, done screen mirroring with the cast settings, it uses your device's cast service. but you have to connect with same wifi both device and tv.

Why does Play Store still show the feature even I disable it in the manifest xml?

I have added the following line into the manifest file but Play Store still shows Microphone in the features and it also says "XX devices removed" for the new APK file. (because of the microphone requirement)
<uses-feature android:name="android.hardware.MICROPHONE" android:required="false"/>
What can be the problem?
You still are requesting that you are using the feature but saying the device does not need the feature to use the app.
therefore the feature will show up because you still use it even though you dont require it.
If you dont want it to show then dont use the microphone
Most likely this is because you're using android.hardware.MICROPHONE instead of android.hardware.microphone. Hardware features are all lowercase.
Since it's not finding a matching <uses-feature> tag, it uses the implicit feature from the RECORD_AUDIO permission.

Different App versions in one APK

This is my problem:
I have an application that requires a certain persmission (Write-SMS) that will of course only function on phones. Now, the app requires that permission for a feature that will be disabled on tablet versions but it won't let users install the app on tablets.
I guess my question is this:
Can I easily create a second manifest for the tablet version, that will be roughly the same as the phone version but without the persmission?
If I'm doing so, is there a way to check what manifest version is being used? I might want to add features to the tablet version that are tablet exclusive and vice versa.
All of course preferibly in one apk, that gets exported and signed once. Thanks for your help in advance!
Simple add:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
To your manifest. The SMS permission automatically asks for a Telephony feature. Adding this tells android that even though you ask for this feature, you don't need it.
Be sure to add an if-else check to see if you can sens SMS from the device before doing so.
I think you must check it in the actual method itself, because permissions can be optional or compulsory, but that's it, not distinguishable for different devices..

android.hardware.telephony breaks installation on the emulator

We're currently revising our application manifest to explicitly use the uses-feature attribute to declare all its dependencies on hardware and software APIs.
Since we expect the user to have mobile Internet, we set android.hardware.telephony to true, but now the app fails to install on the emulator. The error message is:
Failure [INSTALL_FAILED_MISSING_FEATURE]
There is no additional information, not even in the device logs, but I could figure out by trial and error that the telephony feature was causing it.
Since the emulator has support for telephony functionality (you can even simulate dispatching a call), why does this break? And even if it correctly reports that it doesn't support telephony, shouldn't it be obvious that uses-feature was meant to target real devices, not the emulator?
I'm actually quite confused about this attribute now in general, since its documentation seems to imply that it only affects filtering rules for Android Market. I can't see where it mentions that uses-feature has a direct impact of the installability of an app, which seems to go way beyond the merely declarational/informational nature the docs attribute to it.
Maybe it's not a good idea to use it after all? Our build server doesn't execute anymore, since installation to the emulator now always fails...
Basically what you need to use a more recent Emulater with more features supported,or alternatively you can do the following :
1.Comment out or remove the following lines from your Manifest XML file
<!-- COMMENT ME -->
<uses-feature android:name="android.hardware.telephony" />
OR
2.Add the following :
<!-- UNCOMMENT ME and add android:required="false" -->
<uses-feature android:name="android.hardware.telephony" android:required="false"/>
You should be good to go if you do it correctly.
I have an app that uses telephony and works fine with the 2.2 emulator and I presume you have already set the required attribute to false in your manifest:
<uses-feature android:name="android.hardware.telephony" android:required="false"/>
If that's the case, my guess is that there is another feature or permission declared in your manifest that isn't present in the emulator and causing the error. Hunt it down through trial and error.

Categories

Resources