Exactly. That's what I'm saying: Google gives some e-book reader all file access (which it doesn't need, since MD, with media access only, is able to read and write any file type, even if only in directories manually selected by the user in a dialogue, and therefore so could this reader – and such method would be appropriate for the reader) but denies it to MD, which does need it. With all file access MD would be able to fully manipulate files as Tasker does.
Google rejected my request to get all file access.
- Thread starter MacroDroidDev
- Start date
Endercraft
Moderator
I've read through this whole thread again, and this post caught my attention:
When you install the app, you have screens explaining how the app works. Then, most likely at the end, you add a screen that tells the user that for some actions, all files access is required and prompts them for the access.
If they deny it, add a confirmation popup like "are you sure you want to proceed without this permission? The app might not work as you expect without it".
Notice how I wrote app instead of some actions. That could also play a role.
In the end this is like trying to increase the probabilities of winning, except the game is rigged.
Notice this part:
Could it be that whatever is reviewing the app be determining if all files access is a "core feature" depending on when, how and why the app asks for the permission? Imagine this:
When you install the app, you have screens explaining how the app works. Then, most likely at the end, you add a screen that tells the user that for some actions, all files access is required and prompts them for the access.
If they deny it, add a confirmation popup like "are you sure you want to proceed without this permission? The app might not work as you expect without it".
Notice how I wrote app instead of some actions. That could also play a role.
In the end this is like trying to increase the probabilities of winning, except the game is rigged.
I am going to try again but at the moment I have to win the battle of target sdk 34 and get approval to continue running as a foreground service.
If and when I get over this hurdle I'm going to make a big effort to create a compelling video as to why I need this permission when I apply for it again.
If and when I get over this hurdle I'm going to make a big effort to create a compelling video as to why I need this permission when I apply for it again.
Hello all. Brand new to MacroDroid and the forum, so my experience with the solution is minimal (so far). Feel free to write this off as a noob comment!
Been reading through this saga, and I have a suggestion for this, once you win the target sdk 34 battle. I looked at the descriptions in the Play store for MacroDroid, Tasker, and Automate and compared the "file management" sections in context with remainder of the descriptions. I am approaching this from a Sales + UI design background:
- Automate - 2nd line, clearly important, implies core functionality.
- Tasker - 3rd major paragraph down after Automations and Actions, also implies core functionality
- MacroDroid - near the bottom of the description, after "For experienced users", after "Running in background", after "Support", and right above "Accessibility Services".
For the casual reader, the position of the feature descriptions could imply that it is only for experienced users, less important than how to get Support, and barely more important than the accessibility features of the product. Like writing a resume, a sales pitch, or a UI design, you put the most important items at the top of page 1.
Could it be as simple as adding one or more File Management use cases in the bullets at the top? Something like "Automatically backup/copy your files to a specific folder on the device, an SD card, an external USB drive, or cloud storage, if desired".
Been reading through this saga, and I have a suggestion for this, once you win the target sdk 34 battle. I looked at the descriptions in the Play store for MacroDroid, Tasker, and Automate and compared the "file management" sections in context with remainder of the descriptions. I am approaching this from a Sales + UI design background:
- Automate - 2nd line, clearly important, implies core functionality.
- Tasker - 3rd major paragraph down after Automations and Actions, also implies core functionality
- MacroDroid - near the bottom of the description, after "For experienced users", after "Running in background", after "Support", and right above "Accessibility Services".
For the casual reader, the position of the feature descriptions could imply that it is only for experienced users, less important than how to get Support, and barely more important than the accessibility features of the product. Like writing a resume, a sales pitch, or a UI design, you put the most important items at the top of page 1.
Could it be as simple as adding one or more File Management use cases in the bullets at the top? Something like "Automatically backup/copy your files to a specific folder on the device, an SD card, an external USB drive, or cloud storage, if desired".
Last time I tried this I did put this description at the top on advice from the author of Automate. It made no difference so I gave up and removed it from there.
I believe the most important thing is the video I have to submit when requesting the permission to convince them that there is an essential feature. So when I get around to this I will try everything I can to show this.
I believe the most important thing is the video I have to submit when requesting the permission to convince them that there is an essential feature. So when I get around to this I will try everything I can to show this.
Endercraft
Moderator
So apparently it's possible to interact with all files without the helper. Using the shell script action works...