Status Update
No update yet.
Comments
su...@google.com
mt...@gmail.com
su...@google.com
md...@gmail.com
It looks like you are raising an issue as an Android user, rather than an Android Open Source Developer. Our Android Support team will be in contact with you shortly. In the meantime, here are helpful resources:
ra...@google.com
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.
su...@gmail.com
Thank you for reporting this issue. We just need a few things for us to further investigate this issue:
Please fill out each question and comment, thank you.
-
Have you observed this bug on Pixel devices as well?
-
Android Build Version (go to Settings > About Device > Build Number (hold down to copy))
-
Android app name and version if an app related issue:
-
Upload the full bug report file after the issue has occurred. Steps followed here:
https://developer.android.com/studio/debug/bug-report -
Please provide a simple sample project (exported zip Android Studio file) that reproduces the issue. This gives us the closest test environment to yours and allows us to inspect the code/structure used which will help analyze your issue.
-
Steps to reproduce issue specific to the provided sample project: [Be as specific as possible]
- 1
- 2
- 3
-
Expected Results:
-
Observed Results:
Note: Please upload to google drive and share the folder to
The more information we have, the more accurately our product and engineering team can solve the issue. Thank you so much for your time and for your cooperation.
ma...@gmail.com
> 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:
so...@gmail.com
Thank you for reporting this issue. We just need a one thing for us to further investigate this issue:
- Upload the full bug report file after the issue has occurred. Thank you so much.
ai...@gmail.com
to...@gmail.com
to...@gmail.com
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.
Description
Version used: 1.0.0-alpha03
Devices/Android versions reproduced on: Samsung Note 8 (Android version 7.0 and 8.0)
My application has an activity having a simple button. Clicking on the button, it enqueues a periodic work request with interval of 15 minutes. Below is code snippet :
On button click :
============
PeriodicWorkRequest.Builder work = new PeriodicWorkRequest.Builder(
TestWorker.class,
PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS,
TimeUnit.MILLISECONDS)
.addTag("TestJob");
WorkManager.getInstance().enqueue(work.build());
TestWorker.java :
============
class TestWorker extends Worker {
@Override
public Result doWork() {
Log.i("TestWorkManager", "Do work called .....");
}
}
Steps to reproduce :
1. Launch the app
2. Click on the button to enqueue the periodic task.
3. Go to recent app launch menu and kill the app
4. After killing the app, check if the periodic task is getting executed or not
Output :
After 15 mins the task (doWork()) is not getting executed.