Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
No permission request query (Android) at app start — Gideros Forum
  • Home
    • ›

    No permission request query (Android) at app start

    saeyssaeys Member
    edited January 2018 in General questions
    Hi guys, I have a question that might not be a Gideros question, but I ask it anyway

    My app uses the Microphone plugin and so uses the RECORD_AUDIO uses-permission tag in the Manifest. That's a "Dangerous" permission that needs to be granted at first app startup.

    So there should be a permission pop-up at app-startup (it has been before) requesting permission to use the Microphone feature. But there is no request -> app can't use the Microphone methods and crashes at init.

    To get the app to work I need to manually go to the app permissions settings on the device and turn on the mic permission there.

    This goes for my test device with API 25. (Another with API 22 automatically sets the permission, as it should be.)

    Is there something I have missed here? Can I somehow force the permission request to popup?
    +1 -1Share on Facebook

    Comments

    • hgy29hgy29 Maintainer
      Accepted Answer
      Which API did you target when you exported your project ? If you set it higher than 19 (or maybe 22, I am not sure), then android assumes that the app can deal with the newer permission requesting scheme, which is wrong for most gideros plugins

      Likes: saeys

      +1 -1 (+1 / -0 )Share on Facebook
    • saeyssaeys Member
      edited January 2018
      That was it. Was targeting 25. When targeting 22 it worked. (Just noted that the already published app targeted 22, so I must have been wrong in remembering permission request popups... B) )

      (22 worked with buildToolsVersion 26.0.2, no warnings. For the future I hope 22 will continue to work as tools get updated. I guess it eventually comes down to updating the plugins to work with the permissions 23 and beyond.)

      EDIT: Anyway, I think the info on compatible APIs should be in the plugin docs.

      Likes: Apollo14

      +1 -1 (+1 / -0 )Share on Facebook
    • SinisterSoftSinisterSoft Maintainer
      Yes, I think it's 22 (not 19) that still asks for the permissions, that seems to be what I have experienced. Anything above 22 will need it to be done within the app.

      Likes: saeys

      Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
      https://deluxepixel.com
      +1 -1 (+1 / -0 )Share on Facebook
    • saeyssaeys Member
      hgy29 said:

      If you set it higher than 19 (or maybe 22, I am not sure), then android assumes that the app can deal with the newer permission requesting scheme, which is wrong for most gideros plugins

      So I'm staying at Android API 22 as long as I want a working microphone plugin.

      Now, as I just submit an update on Google Play Console I got a warning; from november 2018 all app updates must be at API 26 or later. (august 2018 for new apps)

      Since the microphone plugin (and other plugins?) in its current state only works with API 22 or less I really hope there is a competent saint out there who can update the plugin(s) to work with a newer API with the newer permission schemes.

      Likes: hgy29, Apollo14

      +1 -1 (+2 / -0 )Share on Facebook
    • hgy29hgy29 Maintainer
      It would help if we could somehow figure out a list of plugins that would be impacted
      +1 -1Share on Facebook
    • simwhisimwhi Member
      I've been updating apps today and came across this issue.
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      edited May 2018
      I am updating microphone and camera plugin to request permission the new way. There is a problem though, permission request in asynchronous, meaning that the first call to microphone/camera will fail while the permission request is shown, so it would have to be retried after the user has accepted or refused the permission. And there is no event at gideros side to report is the user closed the permission request window.

      Likes: saeys

      +1 -1 (+1 / -0 )Share on Facebook
    • saeyssaeys Member
      (returning to an old issue, but still :smile: )
      hgy29 said:

      permission request is asynchronous, meaning that the first call to microphone/camera will fail while the permission request is shown, so it would have to be retried after the user has accepted or refused the permission. And there is no event at gideros side to report is the user closed the permission request window.

      Does anyone have a suggestion how to get around this? Pause app load somehow while waiting for permission accept/refuse? It isn't very convenient to have the app crash every very first time a new user starts it (albeit it will work after that).

      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      it shouldn't crash and you should get a status message indicating that permission hasn't been granted yet (depending on the plugin). The trouble is that you need to recheck every now and then to see if permission was accepted. I think you can use APPLICATION_RESUME for this since permission dialog will put app in suspend mode
      +1 -1Share on Facebook
    • saeyssaeys Member
      edited January 2019
      It's the microphone plugin. I assumed the behaviour was consistent with your last comment in May, but now I'm not sure. When freshly installed, the app terminates and I get at crash popup, obviously when a new Microphone object is created (at init.lua:101, see below). A couple of milliseconds later, the microphone permission request popup appears. When Yes is tapped, I can restart the app and everything's working fine.

      Run log from Android Studio:
      E/AndroidRuntime: FATAL EXCEPTION: GLThread 1090
      Process: nu.bildligttalat.booarticulationhelper, PID: 25241
      com.giderosmobile.android.player.LuaException: Permission requested.
      stack traceback:
      init.lua:101: in main chunk
      (luac): in main chunk
      at LUA.MAIN_CHUNK(init.lua:101)
      at LUA.MAIN_CHUNK(luac:1234)
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      yes, you need to catch this exception with pcall in lua and check the error message. I didn't find a better way to do while retaining API compatibility.

      Likes: saeys

      +1 -1 (+1 / -0 )Share on Facebook
    • saeyssaeys Member
      Thanks, an acceptable workaround. :-)

      For those (noobs, me included) in need in this case, here's some info about pcall: https://wait4ideas.wordpress.com/2013/11/02/handling-run-time-errors-in-gideros/

      Likes: Apollo14

      +1 -1 (+1 / -0 )Share on Facebook
    Sign In or Register to comment.