Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uses-feature tag in AndroidManifest file #958

Open
Rix opened this issue Dec 15, 2016 · 3 comments · May be fixed by #2322
Open

uses-feature tag in AndroidManifest file #958

Rix opened this issue Dec 15, 2016 · 3 comments · May be fixed by #2322

Comments

@Rix
Copy link

Rix commented Dec 15, 2016

Is it possible to add uses-feature tags in AndroidManifest file ?

i.e: <uses-feature android:name="android.hardware.usb.host" />

see https://developer.android.com/guide/topics/connectivity/usb/host.html

@frmdstryr
Copy link

Not really a good way, but you can edit the template (AndroidManifest.tmpl.xml) for the manifest in the bootstraps folder.

@KeyWeeUsr
Copy link
Contributor

KeyWeeUsr commented Dec 31, 2016

@Rix That tag is mostly considered an evil, because it filters(hides) your application from other users. If you aren't going to do only and only something related to that single piece of hardware or base your app on it, then use permissions and check for the availability of the hardware later.

I met that tag only for filtering OpenGL and most of the devices should be able to support USB host anyway since api 12 or so. Although I think there isn't a specified permission for USB host directly in AndroidManifest, you may try to use this example without the <uses-feature> tag. It should work and only return null (which means you need to check for it unless you want the app to die).

Other useful stuff I found: example, fancy stuff.

Otherwise you can find a really big list of permissions at #965.

@Julian-O
Copy link
Contributor

Ah! This explains kivy/buildozer#1715

In summary:

  • OP asks for a new feature.
  • Commenters say bad idea.
  • Developer implements it, and submits PRs to p4a to implement a new option, and to Buildozer to call the new option.
  • P4a PR stalls unmerged for 3 years. Buildozer PR is merged.
  • User tries using the feature in Buildozer and is thwarted by the lack of p4a's support.

We need to unblock this PR. Either progress it to merged (and close the Buildozer Issue as fixed) or reject it (and update the Buildozer Issue to say the parameters should be rolled back.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants