Status Update
Comments
ja...@google.com <ja...@google.com> #2
fun RecyclerView.executeAfterAllAnimationsAreFinished(
callback: (RecyclerView) -> Unit
) = post(
object : Runnable {
override fun run() {
if (isAnimating) {
//if isAnimating() returned true itemAnimator will be non-null
itemAnimator!!.isRunning {
post(this)
}
} else {
callback(this@executeAfterAllAnimationsAreFinished)
}
}
}
)
do...@gmail.com <do...@gmail.com> #3
To fix it:
- set horizontal constraints in recycler view
- set recycler view
layout_width
to 0dp
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/recyclerView"
android:layout_width="0dp"
android:layout_height="0dp"
android:clipChildren="false"
android:clipToPadding="false"
android:orientation="vertical"
android:overScrollMode="ifContentScrolls"
android:scrollbars="vertical"
app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toBottomOf="@id/headerTextView"
tools:listitem="@layout/list_item" />
17...@gmail.com <17...@gmail.com> #4
They are supposed to be the same.
The workaround helped, but this doesn't mean there is no bug.
In fact you show there is another bug: there is a difference between those 2 cases.
ja...@google.com <ja...@google.com> #5
sb...@gmail.com <sb...@gmail.com> #6
ja...@google.com <ja...@google.com> #7
sb...@gmail.com <sb...@gmail.com> #8
ja...@google.com <ja...@google.com> #9
sb...@gmail.com <sb...@gmail.com> #10
Are you planning to fix this?
ja...@google.com <ja...@google.com> #11
bj...@gmail.com <bj...@gmail.com> #12
sa...@google.com <sa...@google.com>
de...@gmail.com <de...@gmail.com> #13
ra...@google.com <ra...@google.com> #14
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the bug report to google drive and share the folder to android-bugreport@google.com, then share the link here.
sb...@gmail.com <sb...@gmail.com> #15
I am unable to test anything newer than Android 13, but there is no indication of progress on this bug. In fact, Android 13 aggravated it further with new constraints on app-specific storage, which file managers have struggled to address. Shared storage is the only reasonable option for cross-app content, and it's painfully slow.
This slowdown of shared storage in Android 11 is now widely known and discussed on numerous forums. For examples, try a search like this:
I am not going to post another bug report for this, partly because of the privacy exposure, but mostly because this would be pointless: this issue is a universal Android problem and not related to my specific phone or apps. A simple benchmark like that of the original post would make the slowdown obvious. Please run the posted benchmark script (or one similar) for verification of the problem. Its code and results are here:
As an example of the sort of use case harmed by the slowdown: since the original post, I published a standalone content-folder backup+sync app on the Play store, which allows users to manage content stored on their phones. It's available here:
This sort of app allows Android devices to be used for content storage, content creation, and other PC-level tasks. Shared storage is essentially required for such tasks, because it is never automatically removed. App storage may deleted on both app-data clears and uninstalls, and hence is very poor option for general persistent content.
If Android wishes to support such tasks, it would do well to invest some effort on optimizing shared-storage speed that regressed radically in Android 11. Given that phones now come either 512G and 1T of storage, it seems time for Android to expand its vision and scope, and become more inclusive of users who wish to leverage the full power of the devices they are now buying.
Footnote: newer UFS4 storage chips rolling out to recent phones promise to speed storage in general (perhaps by 2X), and this will partly address the shared-storage slowdown. It's not a fix, though, because app storage will faster too. Shared storage will still be frustratingly slower, much slower than it was before Android 11, and difficult to use for non-trivial content collections. For Android's sake, please improve this.
sb...@gmail.com <sb...@gmail.com> #16
This report is about the slowdown when accessing shared storage with file paths and native-library calls. This impacts portable POSIX file-processing code either migrated from non-Android platforms, or intentionally written to work on non-Android platforms too. Such code took a massive speed hit in Android 11 which remains to this day, and the speed loss is not improved by obtaining the MANAGE_EXTERNAL_STORAGE permission.
Whether this speed hit is also present for file-processing code that accesses shared storage with proprietary Android-only APIs (e.g., MediaStore) is outside the scope of the original post. Either way, rewrites which restrict portable code to run on Android only would be limiting, onerous, and impractical for the vast amount of POSIX file-processing code in the wild.
Please optimize the file-path API's speed for shared storage.
sb...@gmail.com <sb...@gmail.com> #17
A few easily reproduced tests showing the slowdown follow. They use abd shell, which presumably triggers native file-path ops. The test device is a Samsung Fold5, running Android 13 and One UI 5.1.1, with 1T of UFS 4 storage. The timed subject folder is close enough in shared and app-external (a.k.a. app-specific) storage to pass as identical. Reproduce with any substantial folder in both storage areas:
~$ $ADB shell
q5q:/ $ export SHARED=/storage/emulated/0/MY-STUFF
q5q:/ $ export APPEXT=/storage/emulated/0/Android/data/com.quixotely.usbsync/files/MY-STUFF
# demo speed diff
q5q:/ $ time du -k $SHARED > /dev/null
1m16.84s real 0m01.41s user 0m12.20s system
q5q:/ $ time du -k $APPEXT > /dev/null
0m00.52s real 0m00.05s user 0m00.46s system
q5q:/ $ time du -k $SHARED > /dev/null
1m16.11s real 0m01.54s user 0m12.29s system
q5q:/ $ time du -k $APPEXT > /dev/null
0m00.49s real 0m00.06s user 0m00.42s system
# verify same data
q5q:/ $ du -k $SHARED | tail -n 1
241447072 /storage/emulated/0/MY-STUFF
q5q:/ $ du -k $APPEXT | tail -n 1
241447044 /storage/emulated/0/Android/data/com.quixotely.usbsync/files/MY-STUFF
q5q:/ $ du -k $SHARED | wc -l
14936
q5q:/ $ du -k $APPEXT | wc -l
14936
Another data point: as far as can be determined, Android 12's FUSE Passthrough is implemented on this test device. Shared storage access is still slow, whether MANAGE_EXTERNAL_STORAGE is granted or not (though its exact impact is unknown, and the slowdown naturally depends on operations mix):
~$ $ADB shell getprop persist.sys.fuse.passthrough.enable
true
~$ $ADB logcat FuseDaemon:V \*:S
--------- beginning of main
08-18 11:48:55.365 5665 6417 I FuseDaemon: Using FUSE passthrough
08-18 11:48:55.365 5665 6417 I FuseDaemon: Starting fuse...
~$ $ADB logcat | grep FuseDaemon
08-18 11:48:55.328 5665 6414 V FuseDaemonThread: Waiting 1000ms for FUSE start. Count 4
08-18 11:48:55.361 5665 6417 I FuseDaemonThread: Starting thread for emulated;0 ...
08-18 11:48:55.365 5665 6417 I FuseDaemon: Using FUSE passthrough
08-18 11:48:55.365 5665 6417 I FuseDaemon: Starting fuse...
vi...@google.com <vi...@google.com> #18
Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here
Description
Shared storage in Android 11 is 10X to 100X slower than app-private and app-shared storage. This is clearly demonstrated in the new Termux screenshots posted here (see below for direct links):
The first two shots were taken on a Pixel 4a running a stock Android 11 ROM (though rooting has no effect on results). The first mostly exercises stat calls and directory listings, and the second adds full reads of content in trees scanned. Shared storage is 100X slower than app storage in the first, and 40X in the second. A third shot shows no such speed difference on Android 10.
Similar results were also seen on a Samsung Galaxy Note20 Ultra upgraded to Android 11 as logged in the prior thread, and other reports of the slowdown are easy to find on the web.
The original issue-tracker thread culminated in a reply stating that this is intended behavior. I respectfully submit that a 100X slowdown is an extreme regression, and should qualify as a defect that merits repair.
Moreover, the suggested work-around of moving content to app storage is not usable. App storage is inaccessible to file explorers tested on 11 today without rooting, and both app-private and app-specific storage are removed automatically when the owning app is uninstalled. This is not a workable solution for general content storage beyond the trivial.
Please take another look at this issue. As it stands, this seems like a poison pill which penalizes all programs that manage content in shared storage. While some slowdown may be an acceptable trade-off for privacy, 100X makes many devices unusable for the purposes for which they were purchased. Surely this must meet the litmus test of a defect.
--------
Direct links to screenshots: