I just want to note that there doesn't seem to be any system to automatically clear logs from xposed installer.
I was sorting apps by size and found that xposed installer was using 1.36GB!! After clearing the logs the problem was solved.
It would be nice to have a setting to automatically clear the logs (it could be a log maximum size setting, a log maximum age setting or whatever else).
That's all, thanks for this great software!
You have an incompatible module that keeps crashing. Find it, uninstall it. Clearing the logs does not fix the problem.
Q
Olkflx said:
It would be nice to have a setting to automatically clear the logs (it could be a log maximum size setting, a log maximum age setting or whatever else).
Click to expand...
Click to collapse
You're by far not the only one who has suggested this. As a developer, it's surprising for me that many people want to fix only the symptoms instead of the root cause. Anyway, it's planned to limit the log size to avoid such big files, but that obviously doesn't fix anything.
GermainZ already said what you should do, it's also mentioned in the FAQ.
Related
So a friend of mine updated his T-Mobile UK Samsung Galaxy S to the official 2.2.1 JPY firmware using Odin a few weeks ago. This went well, and is the same firmware that I've had on my unbranded SGS since December.
However, he has an interesting problem. Some of his apps (Handcent, Dolphin HD, plus a few others) seem to forget all of their settings every time the app is exited. For example, every time he goes back into Dolphin it enters the setup wizard as it it's being ran for the first time. This doesn't happen on every app, and it doesn't happen every time.
I noticed there are a couple of other threads on here with people reporting similar issues on custom ROMs (with no solution), but this is a stock ROM from samsungfirmware.com and certainly doesn't happen on my SGS, so it's not the ROM to blame.
Anyone know of a fix?
This question posted in the last few days .
jje
As I said in my post "I noticed there are a couple of other threads on here with people reporting similar issues ... (with no solution)". I wasn't being lazy and just starting another thread without doing some research first. I've read the other threads and they do not contain a solution that will work for him.
I'm assuming you're referring specifically to this thread? http://forum.xda-developers.com/showthread.php?t=992335 In my friend's case, rooting is not an option, so this solution won't work for him.
However, based on that it looks like a factory reset may fix it. If I don't come back people reading this can assume it worked.
Hello
I experimented the same issue.
Looking at some log traces event it reported some permissions errors on intestinal filesystem like database location access write errors. This can explain setting persistence trouble.
After various workaround, bypass or others kind of fallback I did a full reinstallation of filesystem including a wipe data of the system. Take care to backup application and sensible data SMS, photo...
Since all is working fine and no more problems with settings
I don't know if it's helping you.
This is just my personal experience on this same problem.
Perhaps more simple solution is possible
Regards
Gilles
Thanks. So far so good after a Factory Reset. If it were my phone I'd be looking at Logcat, etc, too, but it's a bit hard to do remotely.
It's odd how some apps saved their settings fine, but some don't.
A factory reset did fix it... for a while. But then other apps started suffering from the problem.
So I've been researching this a bit more today. Here's what I've discovered:
The problem is unique to Samsung Galaxy S phones, and appears to be only ones running 2.2.1 (but maybe 2.2. too?).
Samsung have renamed /data/data to /dbdata/databases, and shared preferences for applications are persisting in this folder even if the application is uninstalled. If you install the app again, the app becomes a different user from the one that owns the shared preferences.
For example - If you install some random application and you look at its process running with the ps command, it will show as "app_XX", where XX is some number. For our example here let's say it shows as "app_55". When it then saves its settings in /dbdata/databases the folder the settings are saved in will have owner (shown by ls -l) as "app_55" too. That's fine, and normal.
The seed of the problem is sewn when you uninstall the app. Those shared preferences are not removed. Even using the "Clear data" option before uninstalling doesn't seem to help. If you then install the app again and look at the output of ps you'll see the new app is "app_56". The shared preferences are still there from last time with owner "app_55", hence the permissions error when it tries to save its settings, as user app_56 cannot modify user app_55's files.
A factory reset obviously cures it as this, at least temporarily, as it wipes the data in /dbdata/databases.
If you're rooted, you can go into /dbdata/databases and delete the relevent folder for the application that's having the problem. It will be recreated with the correct owner next time the app saves its settings.
I didn't try chown to change the owner to the correct one, but maybe that's a way to keep the old settings and correct the problem.
Bingo. No wonder my titanium backup is not remembering the preference settings.
Anyone else having this issue? After one of the most recent updates, I noticed my storage space dropped by about a gig. I found that the Xposed installer had over a gig of data saved. I went into the app and cleared the logs and got the majority of that gigabyte back, but after a few days it has gone up to a gig again.
There is no option to disable logging, why the sudden change to allow Xposed to keep such a large running log file? I'm on an S4 that is already internal-storage-challenged...
The problem isn't Xposed, it's with one of your modules. See which is throwing errors all around and report it to the module's author.
You called it sir... Greenify module is listed for every error... part my fault, I haven't updated the app to the latest version because the author removed a feature that I like.
Thank you man for pointing me in the right direction!
I don't remember having this problem before, it only happens sometimes and with different results, it's very random.
Scenario A) When I open Xposed, it starts checking for updates and notifies me of every new update, if I go to the "Dowloads" activityand press the reload button, nothing new adds. <-- normal scenario, it always was like this before 2.6.1.
Scenario B) When I open Xposed, it starts checking for updates but doesn't find any new update (and doesn't give out any error, at least on a toast), when I enter the "Downloads" activity, and press the reload button, new updates appear..
Scenario C) When I open Xposed, nothing happens. It doesn't load ANY update or tried to get new ones, even if I had some updates pending to install before, it won't show anything until I enter the "Downloads" activity. There the updates to-do are like normal and pressing reload gets new ones.
Also, I noticed that from 2.6.1 is when I started choosing specific update configuration for some of the modules only (global is STABLE and for some apps EXPERIMENTAL now).
This doesn't only happens to modules, today I had an scenario B when after entering the "Downloads" activity and pressing reload, I got notified of the new Xposed experimental1 update..
I didn't do the "all modules disabled" test because since this is very random and I rarely find updates for my mods, It would mean having xposed disabled maybe for hours/days which sucks
Updates from the repository are only refreshed every 24 hours. The downloaded repo.xml is kept in the cache and still needs to be loaded every time the app is started - unless the app was still in the memory.
So the different situations can be explained like this:
A) The last refresh was more than a day ago, so the installer first downloads the new XML, then loads it.
B) The last refresh was less than a day ago, so the installer just loads the cached XML. When you press the refresh button, the 24 hour limit is ignored, so you see new updates.
C) The app might still have been running in the background, so no refresh was necessary. Or maybe you have cleared the cache, so nothing was downloaded and the XML to load was empty.
It isn't really worth looking into this in more detail as 2.7 experimental1 handles downloads quite differently.
rovo89 said:
Updates from the repository are only refreshed every 24 hours. The downloaded repo.xml is kept in the cache and still needs to be loaded every time the app is started - unless the app was still in the memory.
So the different situations can be explained like this:
A) The last refresh was more than a day ago, so the installer first downloads the new XML, then loads it.
B) The last refresh was less than a day ago, so the installer just loads the cached XML. When you press the refresh button, the 24 hour limit is ignored, so you see new updates.
C) The app might still have been running in the background, so no refresh was necessary. Or maybe you have cleared the cache, so nothing was downloaded and the XML to load was empty.
It isn't really worth looking into this in more detail as 2.7 experimental1 handles downloads quite differently.
Click to expand...
Click to collapse
That explains a lot. However, doesn't fully explains the C scenario, since on it, the main activity doesn't show all the "pending to install but already notified (in green letters) updates", it doesn't show anything, not even any module or download on any of the activities (forgot to mention this), hitting the reload button fixes everything tho.
The question is.. why does the system works like this? Why it has to be that "manual"? (I spend the entire day pressing the reload button lol). Why it couldn't just check for updates everytime the app was loaded / everytime the main activity was opened / or even without the app opened, in the background. Maybe bandwith? not sure otherwise
If the system is changing in the next version (and for now in experimental), yeah we'd be losing time checking there. How does the new system works? does it do anything of the ideas I said just above? I'd love to test it, but im not moving from STABLE releases of xposed, it is way important for me :good:
Thanks a lot for your fast reply!!
RusherDude said:
That explains a lot. However, doesn't fully explains the C scenario, since on it, the main activity doesn't show all the "pending to install but already notified (in green letters) updates", it doesn't show anything, not even any module or download on any of the activities (forgot to mention this), hitting the reload button fixes everything tho.
Click to expand...
Click to collapse
That's really strange, not intended and I never had that situation. Do you have an app that constantly clears the cache? Loading the XML of course happens independently from the 24 hour limit, so the only possible explanation is that the cached file was deleted.
RusherDude said:
The question is.. why does the system works like this? Why it has to be that "manual"? (I spend the entire day pressing the reload button lol).
Click to expand...
Click to collapse
As mentioned, THIS is definitely not working as intended. I suspect something is deleting the file in the background on your system, as I never heard of such issues before.
RusherDude said:
Why it couldn't just check for updates everytime the app was loaded / everytime the main activity was opened / or even without the app opened, in the background. Maybe bandwith? not sure otherwise
Click to expand...
Click to collapse
Sure it's bandwidth. The repository index has grown to about 350 kB and is always growing. The Xposed Installer 2.6.1 has been downloaded more than 1.25M times, 2.4.1 even reached more than 2.5M downloads. That surely includes duplicate downloads, bots, users who decided to abandon Xposed etc. But still, the repository index has been downloaded 4.5M times in May, generating more than 1.1 TB of bandwidth. Now imagine what would happen if the installer checked for updates twice daily, or even in the background (which would also generate bandwidth for the many users who don't open the app daily).
Apart from that, traffic caused for the user, waiting times until the file is downloaded etc.
With the database approach and partial updates, I might be able to lower the update rate a bit, but I don't really see a necessity for that. There are about 10-20 updates per day, which affect usally none, sometimes one or two of your installed modules. And even when there are updates, there is hardly any reason that you have to update right now, instead of half a day later.
RusherDude said:
If the system is changing in the next version (and for now in experimental), yeah we'd be losing time checking there. How does the new system works? does it do anything of the ideas I said just above? I'd love to test it, but im not moving from STABLE releases of xposed, it is way important for me :good:
Click to expand...
Click to collapse
Just check the thread, I explained it there. There are no changes in the framework, only in the downloader, so it won't affect your modules.
rovo89 said:
That's really strange, not intended and I never had that situation. Do you have an app that constantly clears the cache? Loading the XML of course happens independently from the 24 hour limit, so the only possible explanation is that the cached file was deleted.
As mentioned, THIS is definitely not working as intended. I suspect something is deleting the file in the background on your system, as I never heard of such issues before.
Click to expand...
Click to collapse
Well, now that I remember the times that happened I was cleaning some so it may be the reason.
rovo89 said:
Sure it's bandwidth. The repository index has grown to about 350 kB and is always growing. The Xposed Installer 2.6.1 has been downloaded more than 1.25M times, 2.4.1 even reached more than 2.5M downloads. That surely includes duplicate downloads, bots, users who decided to abandon Xposed etc. But still, the repository index has been downloaded 4.5M times in May, generating more than 1.1 TB of bandwidth. Now imagine what would happen if the installer checked for updates twice daily, or even in the background (which would also generate bandwidth for the many users who don't open the app daily).
Apart from that, traffic caused for the user, waiting times until the file is downloaded etc.
Click to expand...
Click to collapse
Yeah, I understand that , well at least on BD you're gonna save some bandwith
rovo89 said:
With the database approach and partial updates, I might be able to lower the update rate a bit, but I don't really see a necessity for that. There are about 10-20 updates per day, which affect usally none, sometimes one or two of your installed modules. And even when there are updates, there is hardly any reason that you have to update right now, instead of half a day later.
Just check the thread, I explained it there. There are no changes in the framework, only in the downloader, so it won't affect your modules.
Click to expand...
Click to collapse
Done. Thanks a lot
And about that "there is hardly any reason that you have to update right now, instead of half a day later", there are flashaholics and there are xposaholics :laugh::laugh:
Thanks mate!
Hello, I discovered a serious problem that I can't understand.
I have Lineage 7.1.1 with microG and privacy guard...I use iShredder and sd maid to clear photo, cache, etc.
Using diskdigger with root, I discover a huge amount of screenshot while I'm using smartphone (using browser, while playing, etc)...I don't understand how this can happen..
I disabled all overlapping permissions of apps
I thank anyone who can enlighten me on this serius issue for me
Don't know how DiskDigger restores data, but is there a pattern to the screenshots, like date and time? Or interval when being taken? And in which path did you find them? Root rights needed to write there? What apps have root access on your phone?
Will try to reproduce the next days, suggesting first with DiskDigger only before installing other apps you mentioned. And not on my daily driver device. I'm fine right now without using anything from playstore there.
WahZooKey said:
Don't know how DiskDigger restores data, but is there a pattern to the screenshots, like date and time? Or interval when being taken? And in which path did you find them? Root rights needed to write there? What apps have root access on your phone?
Will try to reproduce the next days, suggesting first with DiskDigger only before installing other apps you mentioned. And not on my daily driver device. I'm fine right now without using anything from playstore there.
Click to expand...
Click to collapse
Thank you for the reply. Unfortunately DiskDigger doesn't display informations about image (data, location, etc).
Anyway app with root that I have I think are trust: afwall, forcedoze, adaway, root browser, titanium backup.
Scanned /system and /data with the non-paid version of diskdigger for .jpg and .png, LOS 20170328.
In the /data partition I also found recoverable screenshots of me using calendar, configuring afwall, configuring settings, installing apps and browsing. 17 screenshots, for sure not taken accidentally by myself. Then followed by >100 screenshots in jpg format from videos I recorded a few days ago and haven't deleted until now. For example, I recorded a 40 seconds slowmotion video, and diskdigger offers to restore 4 single screenshots from it, each ~20kb in size, from different positions of the video.
First thought was, maybe the task manager takes temporary pics to offer sliding through recent apps when user triggers switching from one app to another.
But for sure I didn't switch apps when taking a video.
So I'm i also interested in an explanation for this.
Maybe next step would be to reproduce if screenshots of the UI is indeed taken everytime user is pressing home or recent button.
scanning /data, same thing, a lot of screenshots that i neved made, using OctOS here
they are probably screenshots used for recent apps screen. you can see them in /data/system_ce/0/recent_images directory
In the Dropbox portion on data I get thousands of logs every day. The name of the log is [email protected] with the numbers varying every time. I try to read them but my skill set is not that advanced. Can a dev take a look at some and see if they can see a cause for it. Cause it happens so often and so much sometimes it will use almost all my memory and I have to reboot my phone. Thank you in advance.
mjohnson4580 said:
In the Dropbox portion on data I get thousands of logs every day. The name of the log is [email protected] with the numbers varying every time. I try to read them but my skill set is not that advanced. Can a dev take a look at some and see if they can see a cause for it. Cause it happens so often and so much sometimes it will use almost all my memory and I have to reboot my phone. Thank you in advance.
Click to expand...
Click to collapse
/data/system/dropbox is where app, kernel and maybe other, changes are collected as part of the Android DropBoxManager class. If this directory is filling up, you have lots of app crashes.
For example, com.levelup.beautifulwidgets is one of the crashed apps. Root explorer is another. You can look at each report and the first several lines tell you the affected package and process ID.
You did clean flash to 8.1.0, right? You might try clearing dalvik and cache in recovery to see if things behave better.
The folks in the nitrogen thread might be able to help you if the crashed are ROM related.
BTW, the dropbox class has nothing to do with the cloud service.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
/data/system/dropbox is where app, kernel and maybe other, changes are collected as part of the Android DropBoxManager class. If this directory is filling up, you have lots of app crashes . . .
Click to expand...
Click to collapse
my solution to this problem was to delete the files in this directory, take ownership with root, and restrict write permissions but since upgrading to Android 9.0 custom rom rooted, my changes will not stick past reboot. Something is overriding my root user's changes. It's not surprising bc this is google's uploader directory and you know how they are about data. I'm not sure if it's hardcoded into android now or if it's PlayServices but I've tried init.d scripts, recovery, and deleting the entire directory. It always reappears with default permissions.
Anyone have an idea how I can get back control over my data partition?
p.s. Sorry for reviving this old thread but I haven't been able to find very much info about this issue