Have you checked to see what apps you have installed are using how much memory. Many apps still run in the bacround and use lots of memory. LL is very efficient on memory, but it cannot give you memory when you have no more room.
Rebooting you phone alone will free up ram, but its good to keep of which apps you have that are memory hogs.
Robert Posey yeah i had a looksee. There was around 140MB free, which is about normal, alas i forgot to check at the time what the footprint of LLX was 🙁
Well, regarding memory use, I am afraid that the figures that you can get are wrong. This is a shame but most tools are only misleading, this is extremely complex. Unfortunately only a few developer specific tools and a proper analysis can be used to compute meaningful levels. Regarding the OOM, this means that one (and only one) of the limits has been reached. Parts of the memory used by the widgets is subject to this quota, and I believe this has something to do with their size. I am trying to find root cause of this, but what I can see is that this mostly hits a few Android versions.
Pierre Hébert Well i’ve got the full SDK installed and i know my way around the kernel so if it happens again i’ll take a closer look. (previous time the lack of sleep from the night before stopped a closer look)
What i find odd, and perhaps this is my lack of understanding of how android fits into this process, is my expectation that destroying and re-creating the widget afresh should have free’d the memory it was using.
Yes it should, at least regarding the memory under control of the app. You can check this by adding a dynamic text “heap free”: it should decrease and increase to the previous level when you add then remove a widget. (Remove this dynamic text after, this is more a debug tool and may decrease overall performances)
D5 Creation
< ![CDATA[
OK, rebooted phone to try it again, and removed three other widgets to see if that helper. it did, OOM hasn’t happened
the 3 widgets were:
an almost full screen Tapatalk
an almost full screen Business Calendar
and a blank widget that was not configured which was hiding under the tapatalk one.
]]>
< ![CDATA[
Have you checked to see what apps you have installed are using how much memory. Many apps still run in the bacround and use lots of memory. LL is very efficient on memory, but it cannot give you memory when you have no more room.
Rebooting you phone alone will free up ram, but its good to keep of which apps you have that are memory hogs.
]]>
< ![CDATA[
Robert Posey yeah i had a looksee. There was around 140MB free, which is about normal, alas i forgot to check at the time what the footprint of LLX was 🙁
]]>
< ![CDATA[
Oh, I missed your post !
Well, regarding memory use, I am afraid that the figures that you can get are wrong. This is a shame but most tools are only misleading, this is extremely complex. Unfortunately only a few developer specific tools and a proper analysis can be used to compute meaningful levels. Regarding the OOM, this means that one (and only one) of the limits has been reached. Parts of the memory used by the widgets is subject to this quota, and I believe this has something to do with their size. I am trying to find root cause of this, but what I can see is that this mostly hits a few Android versions.
]]>
< ![CDATA[
Pierre Hébert Well i’ve got the full SDK installed and i know my way around the kernel so if it happens again i’ll take a closer look. (previous time the lack of sleep from the night before stopped a closer look)
What i find odd, and perhaps this is my lack of understanding of how android fits into this process, is my expectation that destroying and re-creating the widget afresh should have free’d the memory it was using.
]]>
< ![CDATA[
Yes it should, at least regarding the memory under control of the app. You can check this by adding a dynamic text “heap free”: it should decrease and increase to the previous level when you add then remove a widget. (Remove this dynamic text after, this is more a debug tool and may decrease overall performances)
]]>