Fixed
Status Update
No update yet.
Comments
zh...@gmail.com
I have this same problem on a different phone and its driving me crazy lol. Found any solution?
en...@google.com
I also have this problem and with only 1.4gb the file fills the phone immediately. Please address this issue as my phone is virtually unusable. I have to clear the file to use other apps. I have to wait half an hour to regenerate the file to use the camera our three gallery.
cc...@google.com
Me, too!
Thumbnail files become bigger than the combined size of all other photos, so it has to be a bug.
Gallery and Camera become extremly sluggish after a while (because they have to read those massive thumbnail files?). They become responsive after deleteing those files. But the files become autocreated, and keep growing again.
Only workaround seem to ba a couple of hacks that stop the Gallery App from re-creating those darn files (e.g. chmod a-w, or creating directories with those filenames names)
Thumbnail files become bigger than the combined size of all other photos, so it has to be a bug.
Gallery and Camera become extremly sluggish after a while (because they have to read those massive thumbnail files?). They become responsive after deleteing those files. But the files become autocreated, and keep growing again.
Only workaround seem to ba a couple of hacks that stop the Gallery App from re-creating those darn files (e.g. chmod a-w, or creating directories with those filenames names)
cc...@google.com
as far as I know it's a bug from Android, that spread to all devices and there's no official solution at the moment.
The only workaround to temporary fix it is trough command line:
1) delete these files and make the .thumbnail folder read-only
2) create a script that every now and since cleanup this folder
Unfortunately, the CPU consumption will still be there in both cases. Try to use as less as possible the official gallery, and use instead another one (e.g. xperia gallery, or any app)
Ciao
Pietro
The only workaround to temporary fix it is trough command line:
1) delete these files and make the .thumbnail folder read-only
2) create a script that every now and since cleanup this folder
Unfortunately, the CPU consumption will still be there in both cases. Try to use as less as possible the official gallery, and use instead another one (e.g. xperia gallery, or any app)
Ciao
Pietro
en...@google.com
I too have same problem.if any of u find a solution pls mail me
Description
We find that in user mode, the adbd fork new process whose oom_adj is -1000.
Such as, we can see many omm panic in user log:
Line 82: <6>[17721.393968s][2016:02:03 16:05:54][pid:6467,cpu0,kworker/0:2]lowmem_dbg: [10425] 2000 10425 533125 478139 1045 53958 -1000 tewilovesyouyet
Line 175: <6>[17724.392442s][2016:02:03 16:05:57][pid:6467,cpu0,kworker/0:2]lowmem_dbg: [10425] 2000 10425 537221 479523 1048 53958 -1000 tewilovesyouyet
After analysis, in user mode, when the adbd start, it will have ADB_SHELL uid.
the code in shell_service.cpp:
void init_subproc_child()
{
setsid();
// Set OOM score adjustment to prevent killing
int fd = adb_open("/proc/self/oom_score_adj", O_WRONLY | O_CLOEXEC);
if (fd >= 0) {
adb_write(fd, "0", 1);
adb_close(fd);
} else {
D("adb: unable to update oom_score_adj");
}
}
Because the adbd don't have root permision, the code won't work here.
So we suggest if we can set adbd process oom_score_adj to 0 at default.