SFOS 4.5 Android 11 media providers sdcard high cpu

REPRODUCIBILITY: always
OS VERSION: 4.5.0.19
HARDWARE: Xperia 10 III
UI LANGUAGE:
REGRESSION: yes, problem not present in 4.4.0.58

DESCRIPTION:

constant, permanent high CPU usage for com.android.providers.media.module process, and sdcard process.
this is the case on all SFOS 4.5 versions (android11). this is not the case on SFOS 4.4 (android10). i can easily flash back and forth, changing nothing, and always observe this.

i have performed flash to 4.4 and then ota to 4.5, allowing the migration script to chown all my files on my sdcard (WHY???) and it also does not seem to help.

  • changing file uid/gid back doesnt help
  • pm clear com.android.providers.media.module doesnt help
  • .nomedia everywhere legal doesnt help. (side note: media-providers now DELETES .nomedia in Pictures and the sdcard mount dir, and a few other places where i wanted to try it out. i did chattr +i to .nomedia in the root of my sdcard, and media provider just constantly threw exceptions to log until i removed the chattr)
  • reboots dont help, restarting aliendalvik doesnt help
  • nothing in logcat while this is happening
  • kill -9 fixes the problem for about 15min, or until the next reboot

in sfos 4.4, i had about 38000 pictures on my phone being scanned, so it took a few min. i deleted all but around 1000, and now 4.4 is instantaneous, and 4.5 still runs forever. it doesnt seem related to the amount of stuff

PRECONDITIONS:

sfos 4.5, aliendalvik android11

STEPS TO REPRODUCE:

  1. start aliendalvik
  2. wait for phone to burn a hole in my pocket

EXPECTED RESULT:

reasonable cpu usage as media scanner runs for a few minutes on first boot, like in sfos4.4

ACTUAL RESULT:

phone gets so hot you can finally remember which pocket its in

MODIFICATIONS:

ADDITIONAL INFORMATION:

3 Likes

I’ve noticed this process on Xperia 10 II running on 4.5.0.19 as well. However, it didn’t consume too much cpu, but was constantly running on 10-20% possibly for hours until I restarted the Android AppSupport. I haven’t seen the process for a while or at least it haven’t gone crazy like that.

Added to internal tracker

1 Like

with some more testing, i see that it actually only runs for ~60 hours, not forever. every reboot and every restart of appsupport causes it to scan everything again, taking 3 more days. (since i start and stop android from time to time, this is functionally forever, but its important to note that its not a simple bad file its getting stuck on or something.)

the main problem seems to be that it scans EVERYTHING, regardless of .dotfiledirs and regardless of .nomedia, and is VERY slow to scan on the sdcard in android 11. in SFOS 4.4, the same scan on the same data takes 8 seconds every boot.

after running some more tests, and using lsof to see the dirs it is accessing, it seems that SFOS 4.5 aliendalviks media providers scan is at least 20x slower than SFOS 4.4 on internal storage, and possibly much slower on sdcard.

  • scanning a test dir containing 180 photos on the sdcard takes it over a minute
  • scanning a test dir containing 180 photos in ~/Pictures takes around 2s
  • every boot, it scans my ~/.cpan dir, taking around 5 minutes
  • every boot, it scans my ~/.cache dir, taking around 20 minutes
    • my email client uses many small files, and several programs i use write small files to ~/.cache

as a workaround to speed things up a little bit, i made two partitions on my sdcard. i moved a BUNCH of stuff to the first partition, and symlinked from /home. the first partition i mount --move at startup from /run to /media, to stop aliendalvik seeing it. the second partition, i leave in /run so that opencamera can save photos there and coolreader can open books there (and literally nothing else).

mediaproviders now uses 200% cpu for around 5 minutes at startup, instead of 60+ hours. this means i can keep 4.5 for now, but a solution like lineageos’ .noscanandnomtp would be MUCH MUCH better.
if aliendalvik was a little more open, i would try to build+replace media providers module apex myself, but it doesnt seem feasible.

1 Like