Are permissions' names case sensitive ? This works fine:
<uses-permission android:name="android.permission.READ_CONTACTS" />
and that one doesn't:
<uses-permission android:name="ANDROID.PERMISSION.READ_CONTACTS" />
The problem is though, that the latter was automatically created by Android Studio 1.2 when I typed R and pressed enter. Am I missing something or it's a Android Studio's bug?
I am not sure about the bug, but I am sure that intents and permissions are case sensitive.
Related
In my app i include a library that request camera. This limits my application for devices without camera and i need it specifically for a device with scanner but no camera. So i want to make the camera permission as not required in my app. How can i do this.
I added
<uses-permission android:name="android.permission.CAMERA" />
<uses-feature
android:name="android.hardware.camera"
android:required="false" />
<uses-feature
android:name="android.hardware.camera.autofocus"
android:required="false" />
in my apps manifest. Is that enough?
Or should i add tools:node="remove" or tools:node="replace" in my app like as below
<uses-permission android:name="android.permission.CAMERA" tools:node="replace" />
Yes it's enough. You set it to be a non-required feature, so it's non-required.
Just because you use the CAMERA permission doesn't mean the device has to have a camera. You could put in:
<uses-permission android:name="hue.com.derp" />
And it wouldn't restrict your compatibility base at all. If the host device doesn't recognize a permission, it ignores it.
The tools namespace has zero effect on runtime. It's simply for you to provide the IDE with a sample of what might happen during runtime, so it can update previews and the like.
I would say check the device type first if it has camera & 6.0+ then you need to ask for permission other wise just run your code normal
I'm trying to embed the Crosswalk runtime as a WebView replacement in an app with other Java code (i.e. not as a simple wrapper for a web app).
Now their official documentation says you need the following permissions in any case:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
This is a lot!
So I tried with fewer permissions. What I found is that the following permissions are really required in any case:
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
This is okay. So if this was sufficient, it would be a significant improvement over the list given in the docs.
But maybe the others are required in some cases as well. Can someone clarify? In what situations are the other permissions needed? Only when some action is triggered via JavaScript? Then one may use Crosswalk without these, probably, right?
while you are correct about what the official documentation states, it's also true that there is some conflicting information on the crosswalk site.
Specifically, this link buried in the Cordova migration section:
Migrate using command line tools
suggests that:
Crosswalk requires a couple of extra permissions which are not inserted by the Cordova application generator.
and cites specifically:
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
Point is, cordova only adds
<uses-permission android:name="android.permission.INTERNET" />
and therefore one must derive that the only truly required permissions are:
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
as you correctly concluded.
My guess is that the Crosswalk team added to the list the union of all permissions collectively needed by all features/extensions supported by the webview (which includes accessing the camera for WebRTC sessions).
In that regard, the list is appropriate (as quite similar to the ones other stand-alone browsers sport) and was possibly provided to cut short on the explanations.
Btw, I have made a test and removed the "CAMERA" permission from the manifest, and the webview handled the absence graciously (it didn't crash the application, the camera just stopped working and gave a black picture), which seems to point out that you can handle the webview to your users for generic browsing even with the limited set of permissions (but don't take my word on this: I just tried the camera!)
Hope this helps
I'm facing the following problem at the moment:
I have developed app 'A' which uses permissions 1, 2, 3 and uses an 3rd party library 'B' as a dependency (added using maven & gradle).
Library 'B' uses the permissions 4 and 5. Now when building the app, the manifest merger adds the permissions 4 and 5 to app 'A'.
How can I prevent this and only have the permissions 1, 2 and 3 in the final manifest?
My first guess would be using one of the manifest merger markers as seen here: http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger#TOC-Markers
You need to use Selector
Each tools:node or tools:attr declaration can be augmented by a
tools:selector attribute which is contextual information on whether or
not the merging strategy should be applied to the current lower
priority XML description. For instance, this is useful when removing a
permission only if coming for one particular library as opposed to any
library:
<permission
android:name="permissionOne"
tools:node="remove"
tools:selector="com.example.lib1">
It would be next according your initial requirements
<!--suppress AndroidDomInspection -->
<uses-permission
tools:node="removeAll"/>
but keep in mind that all other <uses-permissions/> will be removed.
As you know all libraries have a manifest file and will merge together.
you can remove a permission that is in one of your libraries by this:
tools:node="remove"
for an example removing location permission:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" tools:node="remove" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" tools:node="remove" />
Yesterday I released my app and realised that it is not available for my android 2.3.3 device. (Does not get listet in search results, and when I access the app page directly, android market tells me that it is not available for my device).
The lines of my manifest, which could be the issue (IMO) look like that:
<uses-sdk
android:minSdkVersion="7"
android:targetSdkVersion="8" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-feature android:name="android.hardware.camera.autofocus" />
The only thing I can think of which could make a difference is that I have no SIM card inserted on that phone- but I have Wifi access. (will try it with SIM card in the evening)
Any ideas?
Application requires autofocus camera unless you add `android:required="false" to the use-feature tag.
From documentation, see last if statement:
Filtering based on explicitly declared features
An explicitly declared feature is one that your application declares in a element. The feature declaration can include an android:required=["true" | "false"] attribute (if you are compiling against API level 5 or higher), which lets you specify whether the application absolutely requires the feature and cannot function properly without it ("true"), or whether the application prefers to use the feature if available, but is designed to run without it ("false").
Android Market handles explicitly declared features in this way:
If a feature is explicitly declared as being required, Android Market adds the feature to the list of required features for the application. It then filters the application from users on devices that do not provide that feature. For example:
<uses-feature android:name="android.hardware.camera" android:required="true" />
If a feature is explicitly declared as not being required, Android Market does not add the feature to the list of required features. For that reason, an explicitly declared non-required feature is never considered when filtering the application. Even if the device does not provide the declared feature, Android Market will still consider the application compatible with the device and will show it to the user, unless other filtering rules apply. For example:
<uses-feature android:name="android.hardware.camera" android:required="false" />
If a feature is explicitly declared, but without an android:required attribute, Android Market assumes that the feature is required and sets up filtering on it.
The minSdkVersion="7" and targetSdkVersion="8" but you device is 2.3.3 which equal sdk version 10
This will help you to know the sdk versions
so change the versions range in your manafist file
<uses-sdk android:targetSdkVersion="8" android:minSdkVersion="7" android:maxSdkVersion="10" />
I've been working on an app that originally had no touchscreen requirements specified in it's manifest file, so according to the documentation android.hardware.touchscreen is assumed. Because the app doesn't require advanced gestures, a device with a faketouch screen (android.hardware.faketouch) should also be able to run the app, so I added that requirement to the manifest file for an update.
However, the Android market still lists android.hardware.touchscreen as a requirement (as well as android.hardware.faketouch), and I still can't find the updated app in the market on a faketouch device (HTC Wildfire).
These are the permissions, requirements and libraries I specified:
<uses-library android:name="com.google.android.maps" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"></uses-permission>
<uses-permission android:name="android.permission.INTERNET"></uses-permission>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.autofocus" />
<uses-feature android:name="android.hardware.faketouch" />
<uses-sdk android:minSdkVersion="4"></uses-sdk>
Is this a problem (perhaps the market remembers old requirements, or perhaps the Google Maps library inserts a touchscreen requirement) or is it normal to see both listed when specifying faketouch?
It might be too late but might help someone else looking for same problem
If you want the touchscreen feature to be optional add this to manifest:-
<uses-feature android:name="android.hardware.touchscreen" android:required="false"/>
otherwise it is implicitly taking touchscreen as required compulsarily based on some of your code