When the Mediation or Bidding Coming in the next Update?
The permission write external storage has been denied. This problem is coming in my app after update it was working fine before.
Even it takes too long time to get approved it is more than three days now my app have been not approved I have even sent mail to @diego but he haven’t replied please can you take a look on my request and can you fix this waiting approval in the new update
Hello @Vishwas is there any way to solve this as we are waiting for new update release
Because Google Play have said that
We reviewed Watani Wetu | Simba Vs Yanga, with package name com.watani.sc, and found that your app uses software that contains security vulnerabilities for users. Apps with these vulnerabilities can expose user information or damage a user’s device, and may be considered to be in violation of our Malicious Behavior policy.
See the screenshot
Storage Permissions (
READ / WRITE) and DefaultFileScope
DefaultFileScope (AI2, Kodular:
DefaultFile) property in the Designer doesn’t convince me at all. I consider this to be dispensable / superfluous (not to say: confusing).
(Unlike AI2, this does not declare any permissions in the Manifest if
DefaultFileis set to
Why shouldn’t the storage permissions be declared like this (on all Android versions):
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" />
or this (since AI2 & Kodular decided to declare
requestLegacyExternalStorage=truein the Manifest, so it continues to work on Android 10):
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="29" />
I have already asked this question on the AI2 forum many times and have not yet received an answer.
Since storage permissions are requested since API 23 (Android 6) at runtime, it should not be a problem / disadvantage at all to always declare them in the Manifest.
Only on Android < 6, storage permissions (
READ / WRITE) are requested and granted at install time to be able to install an app.
You can remove them from the Manifest if the app doesn’t need them and if you don’t want users to have to grant them. However, this was also the case before.
So I would like to hear a single argument against my proposal.
The huge advantage, however, would be that it would simplify a lot and prevent countless permission bugs and issues. I have pointed this out in countless topics and posts in the AI2 forum.
Yap, though it works fine when I use my Android version 9 but with samsung galaxy a13 5g it shows this error even if you allow permission on the Settings
I think this is why Google Play Team have rejected my app by saying that I am using a software that contains security vulnerabilities for users… expose user information & damage a user’s device
Please kodular staff do something on this we are real in trouble
This post was flagged by the community and is temporarily hidden.
Download component incorrectly requests
WRITE permission also on Android 11+.
Since a file is downloaded to the
/Download, no storage permissions are required on Android 11+.
Screen Orientation Quick Flip
Tested on Redmi Note 7 (Android Version 10)
Auto-Rotation property was also locked.
Screen Orientation was set to Portrait in designer section.
Flipping only occurs when holding in landscape position, it works properly when holding in portait position. (This behaviour not observed in apps created with Android Studio)
Projects affected by this bug will automatically be recovered/fixed when the update is released. Thank you for your patience
Good to hear that. Can we definitely count on that?
And, as I said before, the
File component should always declare both storage permissions (
READ/WRITE) in the Manifest.
WRITE permission only up to Android 10 (API 29). However,
WRITE should not (never) be requested on devices running Android 11+.
Or even better: Storage permissions should always be declared this way in the Manifest on all Android versions!
I have tested the fix with a broken project on my local instance of Kodular. Because workspaces fail to load as soon as malformed blocks are encountered, corruptions won’t be saved in our servers. Effectively, we’re still storing the pre-1.5.5 version of the affected blocks workspaces.
Is it really asking too much to get a short answer/feedback from the Kodular team on my suggestion?
How about if we could test it on the test (beta) server beforehand?
3 posts were split to a new topic: Build failed due to issue from blocks