If you uses this component 
Then it will ask permission on screen Initialize.
I don’t think you can change something here.
As @Taifun asked
Answer this maybe he has some solution for you.
I will test this of course and will report result here
Ok my blocks are working properly, but the query overlays the notifier instant.
It’s not even time to read the Notifier at all.
I therefore have to give the hint before changing the screen. But this is not user-friendly. I will leave it as it was before and give a reference to it on google play store entry or the data protection declaration.
Thanks for looking into it @Taifun @themaayur
1 Like
are you saying, you now additionally added a Notifier in Screen1.Initialize?
unfortunately you did not answer the question…
what happens, if you disable all these blocks? do you still get the permission request window?
so let’s assume, you do not get the permission request window after disabling all blocks in Screen.Initialize then you can put a Notifier.ShowChooseDialog into the Screen1.Initialize event and move all your other blocks from the Screen1.Initialize event to the Notifier.AfterChoosing event
Taifun
No this does not work. Even if that screen.initialize is not used, the request appears.
I already tested what you said! thanks
Ask your users to agree the phone call permission manually.
There is a new problem. If the user denies access and later clicks backpress (coded: gotoscreen, getscreen screen1, close screen a.s.o), the app crashes. If the user agrees, this does not happen and the app continues to run as expected and switches the screens as usual coded.
Post a test aia. Describe exactly the steps to reproduce this issue:
- do this
- do that
- …
Tested with .apk on a Android 7.0
Open the app.
Click on “Go to Screen2”
DENY the permission to make phone calls
Backpress the screen2
phonecall.aia (4.7 KB) phonecall.apk (5.0 MB)
Yes, there seem to be several issues (bugs) related to permissions once again.
Your app works with AI2 without any problems. No (dangerous) permissions are requested there, except for READ permission.
AI2 → permissions from your test aia [AI2 → APK: phonecall2.apk (3.3 MB) ]
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
Kodular → permissions:
<uses-permission android:name="android.permission.CALL_PHONE"/>
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.READ_CALL_LOG"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS"/>
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
Thanks for taking a look into it. Always reliable and clear in the language.
see also here: Lets have some fun!
Does my APK (AI2) phonecall2.apk work on your device (which Android version? )?
(I haven’t changed anything in your aia.)
Yes. No permission request. Would be great, if kodular could drop off this permission from the dangerous list.
Unfortunately, the problem is not resolved by removing the unnecessary permissions from the Manifest.
As soon as you add this block:
the following permissions are also declared in the Manifest (AI2):
<uses-permission android:name="android.permission.READ_CALL_LOG"/>
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS"/>
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
This should always be the procedure, how and when permissions are declared and requested.
Namely, whenever they are actually needed (at runtime / ≥ API 23).
Please have a look at this: @Kodular
I use activity starter!
This works without any permissions and and matches my needs.
reason:
from Google:
App rejected!
Issue: Violation of Permissions policy
After reviewing your app, we found that it doesn’t qualify to use the requested permissions for the following reason(s):
Requested permissions do not match core functionality of the app
You declared Default SMS handler (and any other core functionality usage while default handler), Default Phone handler (and any other core functionality usage while default handler) as the core functionality of your app. However, after review, we found that your app does not match the declared use case(s). Learn more about permitted uses and exceptions.
Please either:
• Make changes to your app so that it meets the requirements of the declared core functionality or,
• Select a use case that matches your app’s functionality
No default handler capability
Default handler capability for Default SMS handler (and any other core functionality usage while default handler), Default Phone handler (and any other core functionality usage while default handler) was listed on your declaration form, but your app does not appear to have default handler capability. Please submit a revised Permissions Declaration Form and/or add default handler capability to your app.