IssueTracker

Attached sample which also includes install permission, to show that indeed this affects third party app store apps, as well as file manager apps.

This is a dumb issue

To witness how important this is, check these links:
https://www.reddit.com/r/androidapps/comments/gdwztw/on_android_r_no_app_can_let_you_see_whats_inside/
https://www.reddit.com/r/Android/comments/ge08ew/on_android_r_no_app_can_let_you_see_whats_inside/

Update for Android R DP 4:
Instead of null or empty list, I get to see "media" folder, but only if I use SAF. Getting storage permission doesn't let you get it.
And of course, access to the rest of the sub folders is blocked.

:(

@5 Actually I've accidentally tested again on DP3 instead of DP4. Current way it seems to work is:

1.Getting only storage permission allows you to see the existence of the "data", "media" and "obb" folders, but you can enter only "media" folder and read other files from "Android" folder.

2.Granting storage+install permission, you get access to "obb" folder too, but not to "data" folder.

3.The "Files" app lets you enter "Android" folder, but shows only "media" folder inside of it. If you copy files into "Android" folder, it will show them for you.

4.Using SAF, you can't see anything except "media" folder there (and normal files you've got on "Android"). Meaning you can't see "obb" and "data", and that you can access only "Android" folder and "media" folders.

Attached sample project. The information is shown on the logs.

It looks like you are attempting to access OBB files via SAF. If you try to read and modify OBB files directly using the file paths instead you should be able to get access after getting the INSTALL_PACKAGES permission.

@7 Read just one comment above yours...
SAF can't help, as I wrote, to reach any folder except "media" and the files of "Android".

File API can reach "obb" folder too, but not to "data" folder.

In short, we still can't reach all files on Android folder via our own device, but somehow a different device can do it via USB, given the permission.

We grant an app 2 permissions on the current device and even that isn't enough compared to a single one for a different device.
And even system apps can't reach it. I've tried using Files app, and it failed to even show that those folders exist.

Beginning with Android 11 no apps can read another app's "data" directory. The reason is to protect apps from other apps that may want to steal their information. Accessing files via USB is OK. We are not trying to prevent Android uses from accessing their own data. The default Files app will be updated in an upcoming release so that users can see their own files in Android/data but the files will still not be globally readable by other apps.

"Beginning with Android 11 no apps can read another app's "data" directory"
-Why not? It's a public folder. Always has been. Was never a trusted place to put sensitive data. For that apps have the private storage path.

"The reason is to protect apps from other apps that may want to steal their information. "
What information? Apps shouldn't put important stuff there.

"Accessing files via USB is OK."
A sentence before you wrote you don't want others to steal information from there.

"We are not trying to prevent Android uses from accessing their own data"
But you just did. Users are supposed to know the files that take space out of their storage there. Users are supposed to have the freedom to see those files, to be able to do backup&restore, to be able to have a file manager that is at least as good as on their PC when looking at their own device storage. Or a storage analyzer.
Currently we can't do anything with this folder. Not even be able to know its size.

"The default Files app will be updated in an upcoming release so that users can see their own files in Android/data"
What if I want to do it using a third party file manager app?
How about a file-manager permission?
Why shouldn't storage permission do it?

@na...@google.com: The problem here is you're not explaining or providing any reasoning behind the change. This leaves users to quite rightly speculate about what you're really trying to accomplish. Explaining your motives is a fundamental principle of change management in organizations; it builds trust, mitigates suspicion, and prevents rumors.

Right now to me and many others it sure seems Google is blindly trying to turn Android into a locked down, iOS clone that's effectively a dumphone with a display glued to it, perhaps hoping that eventually end users won't notice the difference and opt for Pixels instead of iPhones.

So, to be direct and avoid speculation: why is Google making this change? To be clear, I'm not interested in what the change is. That's already been covered. What is Google trying to accomplish by making this change?

It's crazy how it's always "security" reasons tbh. Be it rooting or simple things like this... I really wonder how Windows and Linux survived all these years. Please give us an actual reason, why after a decade this is suddenly necessary. Don't butcher your OS without even telling the users why it is strictly needed.Taking away the users freedom won't exactly make people want using Android more.

AT mc...@gmail.com: It's because Google's Android team largely lacks imagination when it comes to platform vision. The only thing they seem pretty good at doing is blindly following everything Apple does on iOS, including incorporating bugs (the iPhone X's notch) as features. I suspect this malaise extends to security too. Rather than leveraging its ownership of VirusTotal to do actual hardcore automated Play Store scans, they're cribbing Cupertino's playbook and making the OS less useful. It's so mindnumbingly frustrating that no one in Mountain View seems capable of thinking any different (pun intended.)

To anyone at the dev team reading this: if you strongly disagree feel free to explain why you're doing what you're doing to this platform. We're very interested in what you have to say.

Google is going to the same direction like Apple. It looks that "sharing" obb files is coming to its end.
OT: Just wait that they fully patch Safetynet than bye bye Magisk hide and patched bootloaders...

This is a huge issue for those of us who primarily use other file managers, and badly behaved browsers that store downloads in /sdcard/Android/data (I've had chrome do it)

Restricting the Android folder should be in Developer Options rather than blocking it for all USERs!

One thing: Instead of blatantly blocking it, why don't you create an extra permission for it that needs to firstly be enabled via developer options. This would place it behind a triple user barrier (enable dev options, turn permission on, grant permission) and be available for those who really want/need it.

You can also add a security info popup, that really isn't hard to do. The permission itself would be the only real work on that.

@na...@google.com : Please don't limit Android to a dumb OS. Android really stands for possibilities and being open for users no matter how much into the tech they are.

Please reconsider making this just a more "wantable" feature. That would be a golden middle ground.

@17 Requested here about developer options:
https://issuetracker.google.com/issues/158502558