IssueTracker

Adding 2 screenshots and a Termux log to illustrate the issue.

Adding another log showing that an attached USB drive isn't accessible by pathname in wireless ADB either.

And on more shot of the drive in a file explorer.

Update: there is another report of this issue, on the Samsung developers forum:

    https://forum.developer.samsung.com/t/usb-massive-storage-not-recognized-in-galaxy-s20-android-11/9758

No, this is not a user issue.  I am a developer building programs on and for Android.  I and other developers (please see the Samsung developers thread link) are experiencing this show-stopper issue.  

Again: as of Samsung's Android 11 upgrade, an attached USB drive is no longer accessible to programs at its former mount point, "/storage/xxxx-xxxx" (where the xs are the drive's Android ID).  This path pattern still works for an embedded micro-SD card, but not for USB drives--only.  

This is huge for programs like mine which use the file API in the C library (NDK).  Without access by device-agnostic paths, programs must allow for USB as a special case everywhere, and expand IO operations to handle them uniquely, using proprietary Java-based API code that's inconvenient for C-based programs and would be required on Android alone.

I would be happy to learn that this is a Samsung-only issue, but have no way to test this.  Surely, the AOSP team does; simply attach a USB drive and run a wireless "adb shell ls /storage/xxxx-xxx" using the drive's ID to see if the drive's former mount path still works on Android 11.  If this works, it's a Samsung issue, and has already been raised in its forums.  Given that file explorers seem to open files with content URIs in 11, though, my bet is on it being an issue in Android itself.

Thanks for your attention.

Sure:

>    Have you observed this bug on Pixel devices as well?
No.  (I have only Samsung devices to test, and have been able to install Android 11 only on a Galaxy Note 20 Ultra to date.  I suspect this is an Android issue based on file-open behavior of file explorers on 11, but may be wrong.)

>    Android Build Version (go to Settings > About Device > Build Number (hold down to copy))
RP1A.200720.012.N986U1UEU1CTL4  (Aside: hold down does not seem to copy; does developer mode prevent this?)

>    Android app name and version if an app related issue:
N/A.  (This has been seen in ADB commands, so it's cross-app (but was also verified in Termux and Pydroid 3 apps.)

>    Upload the full bug report file after the issue has occurred.
N/A.  (This is a persistent, global condition, not a crash.  If you require a bug report anyhow, please let me know.)

>    Please provide a simple sample project (exported zip Android Studio file) that reproduces the issue.
N/A.  (This is a persistent, global condition.  The first observation was in Python code which ultimately runs C-library file API calls via NDK, but this is not relevant.)

>    Steps to reproduce issue specific to the provided sample project: [Be as specific as possible]
As noted previously:

1 Connect a PC to a phone by wireless ADB
2 Insert an external USB drive into the phone
3 Run command "adb shell ls /storage/xxxx-xxxx" on the PC, where xxxx-xxxx is the Android drive ID

The Android drive ID is available in many file explorers, including Total Commander. This will produce an error message if the drive is not available at its former mount point.  Alternatively, an "ls /storage/xxxx-xxxx" command run at the Termux app's command line on the phone itself will have the same effect without requiring an ADB connection.
 
>    Expected Results:
If the bug doesn't exist, the ADB command should generate a listing of the USB drive's top-level content, as it does on Androids Oreo through 10 (and likely earlier).

>    Observed Results:
For my USB drive:
~$ /.../android-sdk/platform-tools/adb shell ls /storage/8145-191C
ls: /storage/8145-191C: No such file or directory

> Note: Please upload to google drive and share the folder to android-bugreport@google.com, then share the link here.
I have uploaded all the files previously attached here to a Google Drive folder, which should be accessible at:
    https://drive.google.com/drive/folders/1TQT5XxTulLdn_Ke70yRD10TCPLib__Kh?usp=sharing

A full bug report has been uploaded to the Google drive folder noted in my prior reply.  Its direct link:
    https://drive.google.com/file/d/1mjE1JN6kP2r8pWRqDpTtyEMOlmKl7c8M/view?usp=sharing

We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

UPDATE: Samsung has replied that they cannot do anything about this, because it is a new Google policy as of Android 11.  The reply clarified the "/storage/UUID" paths can no longer be set.  It also verified that USB drives can still be mounted at path "/mnt/media_rw", but this is of course not accessible to most programs and users.  

Assuming that qualifies as official, this means that it's not limited to Samsung devices, and the ball is in Android's court.  Please consider restoring general USB access; this is crucial functionality for many use cases, and seems to have been erroneously removed from legacy apps.

It has now been verified that general access to USB mount paths is also absent on a stock Pixel 4a.  On the Pixel, they are available at "/mnt/media_rw" after rooting, but this is not a general solution: rooting doesn't help apps which do not request super-user access; rooting can break apps that check SafetyNet; and rooting is not an option for many (and probably most) users and devices.

To be fair, it's unknown if USB was ever accessible on Pixels as it was on Galaxies, and it's reasonable to put USB-drive access behind a user toggle in Settings.  But an absolute revocation like that current in Android 11 kills existing programs which rely on USB for non-trivial content management, and are unable to invest in major recoding work.  Please consider addressing this; Android 11 is unusable for many users as it is.

As a follow-up idea: if general access to USB mount points is too much of a security concern to allow even as a simple Setting, it might suffice for many use cases to add a Developer Options toggle or ADB command that enables it on demand.  That way, knowledgeable users could choose to use USB drives as before, but more naive users wouldn't be exposed to the risks.

This would be functionally equivalent to user approval of app requests, and could naturally come with a warning.  But it would be especially helpful for C++/POSIX programs based on the File API.  Without USB-path access, the rewrites required to support USB in such programs are so extensive that they often won't happen, leaving slow and unreliable alternatives for users with non-trivial content collections.  With at least developer-level access, programs that rely on USB for content management would be able to advise users on the option, and defer or avoid prohibitively costly rewrites.

Restoring the former USB accessibility would be preferable, but a simple work-around that helps those who need it while not harming those who don't seems a reasonable compromise.  At any rate, please consider some action on this; for many, USB access is one of the main reasons to use the Android platform.

Postscript: this bug report was largely about USB-drive access in Python code run in the Termux or Pydroid 3 apps.  After this report, I published a standalone content-folder backup+sync app on the Play store which works around the issue, and is available here:

   https://play.google.com/store/apps/details?id=com.quixotely.usbsync

As a standalone app, this is able to request Android's All Files Access permission (MANAGE_EXTERNAL_STORAGE) to regain file-path/POSIX access to both removable USB drives and on-phone storage.  The app still uses Python code to access files (ultimately, with native C-library calls), but this works for both USB drives and on-phone storage with the user-granted permission.

This approach restores the USB-drive access taken away in Android 11.  I would almost mark this as a solution, except that building standalone apps to get USB access is fairly onerous.  This was a multi-month task, and seems unnecessary: users who attach a USB drive are implicitly granting access to it.  Moreover, All Files Access is conditional on Play-store approval; many types of apps cannot use it, except for sideloading.

That said, this issue was closed without a change.  We'll have to settle for standalone app development to run file-path/POSIX code and libraries on Android.