Unloaded from memory while using web browser

[barbaMimmo]

[barbaMimmo]

The filter deactivates and the app gets unloaded from memory (not from cached apps) after just a few minutes or even just seconds of web browsing or any other "medium-heavy" operation. I am now on RedMoon 3.2.0 and Android 4.4.4 on a Sony Xperia and a Samsung Galaxy Tab, both unrooted and stock firmware. The web browser I use is IceCatMobile 45.7 but it happens also on system's web browser. I have almost only the web browser, the keyboard and 4-5 fundamental system services running and almost no other cached when this fail happens.

It seems to be a system's memory management issue, but I noticed it got worse with most recent releases of RM. I mean, the time RM stays on and enabled is shorter than before.

Could this be considered a request for enhancement, since optimizing memory usage could lighten the problem?

[barbaMimmo]

As I wrote in other discussion before: insteas of just trying to reduce the memory usage by RM, you could maybe think of a recursive auto-reload of it when it goes offloaded, as long as the user set the filter as desired. One service which behaves that way is "Bluetooth Share": it often gets unloaded, but auto-restarts after a little while, unless you disable it from fast-settings or settings-management. Would that enhancement require root access?

At least, could you keep something like a static notification on the bar, which woul allow the user restart the filter from notification bar without getting back into the home to press on the RM icon?

Oh, and another thing: why don't you keep a notification active even when the filter is manually paused? Now, to re-enable it you have to go back into RM settings, which is uncomfortable.

[smichel17]

(not from cached apps)

If it were a memory issue, I would not expect to see it in cached apps, so maybe it is not a memory issue.

It seems to be a system's memory management issue, but I noticed it got worse with most recent releases of RM. I mean, the time RM stays on and enabled is shorter than before.

As far as I can tell from a little testing just now, Red Moon's memory usage is ~72MB in v3.2.0 and v2.9.2, and ~100MB in v2.10.2. So, that's another strike against it being a memory issue.

I only tested on my physical device and it may be different based on Android version as well. If you want to check on your device, go to Settings > Developer options > Running services (note: it may be named slightly differently)

I'm not planning on doing any performance optimization until I'm done with features; I haven't done any profiling, so I'm not really sure where that all comes from, but it seems like a lot of memory for such a simple app, so eventually I would like to see if I can get that number down a bit.

One service which behaves that way is "Bluetooth Share": it often gets unloaded, but auto-restarts after a little while, unless you disable it from fast-settings or settings-management. Would that enhancement require root access?

It does not require root access and this is what I will look into doing, first.

Oh, and another thing: why don't you keep a notification active even when the filter is manually paused? Now, to re-enable it you have to go back into RM settings, which is uncomfortable.

On newer devices, there is a "quick settings tile" for this purpose. On all devices, the notification should stay active, but there seems to be a bug with this on older android devices. So far, I have not been able to replicate it -- see #97. Changes in #193 will fix this indirectly because there will no longer be a state where the notification can be swiped away, which seems to be the problematic one.

[barbaMimmo]

Hello, you are right in fact, it was my basic mistake: I misread the list of cached apps or read it in the wrong moment. Now I checked several times and can say it's true that RM always gets unloaded from cached app also.

Anyway, doing some wandering around developer setting led me to use a "show CPU usage" option, which draws a transparent layer with data about running services. It's maybe interesting to compare it to the behaviour of RM: this one (okay, it's a system service with high priority, probably) continuously updates itself and never gets killed or unloaded from memory. Couldn't RM do the same? I mean, updating itself more frequently (a sort of "ping" into memory to stay awake) so it wouldn't get kicked off?

Moreover, I tried to notice in what conditions RM gets unloaded exactly, and I never saw any particularly high memory usage by other apps (including org.gnu.icecat) in that moment. For example, RM got unloaded right now while I'm writing here, and this is definitely not a complex page... Oh, by the way IceCatMobile has a memory usage of 200 MB average - 450 MB maximum.

The maximim memory usage by RM at all times on my devices is just 14MB.

Do you need some logcats to investigate? Could "activate OpenGL tracks / Logcat" setting in developer option be useful somehow for our tests? I also wanted to try avoiding usage of system's input method, which seems too heavy for my tastes, and maybe related to the kickoff of RM from memory. Do you think I could try "Hacker's Keyboard" or any other trustable FOSS keyboard instead?i

[smichel17]

Wow, what a difference in memory usage between devices.

If Pause in secure apps is enabled then Red Moon will check the active app once per second, when the screen is on.

I am not really familiar with how to test why this is happening, to be honest. When I get around to fixing this, I will do so for now by periodically checking if the service has been killed without warning and restarting it if so.

This may not be the best long term solution but it's good enough for now, so the app will work for you while I focus on features.

[smichel17]

Wow, what a difference in memory usage between devices.

I believe most of the difference is due to the difference in pixels between our screens. I did the math, and this suggests that the other parts of Red Moon are using ~4.5MB. That is to say, unless there is a way to optimize how much memory we use per pixel (I don't think there is), optimizing for memory usage is a very low priority. (I will still look into restarting the service).

[barbaMimmo]

Fully agree. In fact, the memory usage by RM is already small expecially on those problematic fevices where a recursive reloading into memory when unloaded should lighten the described issue.

[smichel17]

253 will solve this, so I will close this as a duplicate.