That sounds more like a problem with the ROM: but it doesn't have anything to do with your original argument. Various ROMs are known to have the problems where they can freeze (usually because of OpenGL), but that's completely unrelated to Android's scheduling policies for memory and cpu.
Kris On Fri, Jun 21, 2013 at 1:08 PM, Ivan Padarev <ivanpfitn...@gmail.com> wrote: > For example Scout, which is navigating app, cause the phone to freeze and > even restart the phone. > > On Jun 21, 2013 9:54 AM, "Kristopher Micinski" <krismicin...@gmail.com> > wrote: >> >> That depends on a lot of things. It could be that your ROM just sucks >> and has a bug, this is pretty common since some vendors doesn't write >> good code: it's not necessarily a factor in the app. It could also be >> the apps you're using: if you have foregrounded services running then >> they probably shouldn't be. There *are* cases where spammy apps abuse >> Android's scheduling. These are (in my mind) bugs in Android, but not >> inherent design limitations. So if you have apps that are (e.g.,) >> keeping GPS connections, keeping foreground services, etc..., then >> those should be stopped. It could also be a hardware problem, but we >> can't really diagnose without more information about your environment. >> >> Kris >> >> On Fri, Jun 21, 2013 at 10:51 AM, Ivan Padarev <ivanpfitn...@gmail.com> >> wrote: >> > Ok, I understand what you are saying and this is good, but why sometimes >> > I >> > have to do system clean and stop the processes in order to cool down my >> > phone and stop battery drain. Its like some app got stuck and doesn't >> > want >> > to close and the phone starts to heat and the battery got sucked >> > >> > On Jun 21, 2013 7:33 AM, "Kristopher Micinski" <krismicin...@gmail.com> >> > wrote: >> >> >> >> The fundamental part you're misunderstanding is that you somehow think >> >> that if there is "almost zero" RAM usage the system will be any >> >> lighter or faster. >> >> >> >> But I think you neglect these points in your considerations: >> >> - "using more" RAM does not translate into power differences. It's >> >> not like you're paying one 1 uAh for each byte you use or something: >> >> if you have the memory on, you have the memory on. >> >> - Using less memory will likely cause the system to be *slower*. >> >> Why? Because when you have to read data from flash, SD, reload it >> >> from the internet, etc..., you are wasting power that you could have >> >> otherwise saved by caching the app in memory. >> >> - Killing the app in a greedy fashion will also likely hurt the user >> >> experience. Loading from external storage takes a while, and >> >> reloading everything associated with an app when you load it up again >> >> means wasting a lot of power and waiting a long time. >> >> >> >> Kris >> >> >> >> >> >> On Fri, Jun 21, 2013 at 8:27 AM, Ivan Padarev <ivanpfitn...@gmail.com> >> >> wrote: >> >> > When I open the task manager I can see which app is working and how >> >> > much >> >> > memory is using. I mean that even the app not doing any job, still >> >> > uses >> >> > memory, as I see that how the android platform was made. However I >> >> > don't >> >> > like that, because from 1Gb I have less than 100Mb free memory most >> >> > of >> >> > the >> >> > time. I would want this to be changed and android platform made very >> >> > light >> >> > and fast as an operating system. >> >> > >> >> > On Jun 21, 2013 6:46 AM, "Kristopher Micinski" >> >> > <krismicin...@gmail.com> >> >> > wrote: >> >> >> >> >> >> On Thu, Jun 20, 2013 at 10:14 PM, Ivan Padarev >> >> >> <ivanpfitn...@gmail.com> >> >> >> wrote: >> >> >> > Hi I would like to contact android developers, and ask them : >> >> >> > 1.Why an app in order to run will want so much access to so many >> >> >> > things, >> >> >> > that are not part of it function???? >> >> >> >> >> >> Because permissions map to gates on the API, so if you use one >> >> >> method >> >> >> guarded by that permission, you need the permission. >> >> >> >> >> >> > 2. Why there is only one accept for all the permissions???? must >> >> >> > be >> >> >> > separate for different things and anyway going back to the first >> >> >> > question????? >> >> >> >> >> >> Because separating them would require a redesign of the API that >> >> >> would >> >> >> require dynamic security checks on the app's side, and automatically >> >> >> doing this within the API is non trivial. As an example, what >> >> >> happens >> >> >> if your app uses the internet but you don't want to give it access >> >> >> to >> >> >> the internet? Do you just throw exceptions at those times? Then >> >> >> the >> >> >> app will probably crash.. >> >> >> >> >> >> > 3. Why all the apps must work on background if I don't use them >> >> >> > all >> >> >> > the >> >> >> > time, but once a week or so and use my RAM without any >> >> >> > reason.????? >> >> >> > I want a rule that an app must not work on the background unless >> >> >> > permitted >> >> >> > strictly by the user and even to work only when I use them and >> >> >> > when I >> >> >> > close >> >> >> > the app to stop working at all. I want to have enough free RAM for >> >> >> > the >> >> >> > things I use. Also some apps work secretly on background even if >> >> >> > they >> >> >> > are >> >> >> > marked as "don't work on background" I need someone to fix this. >> >> >> >> >> >> This is incorrect: you are misunderstanding how Android works. The >> >> >> app isn't "running" in the background. It's not typically doing any >> >> >> work. It's just sitting there. The way Android's scheduler works >> >> >> is >> >> >> based on a queue of apps which --- when filled --- get "kicked out" >> >> >> of >> >> >> memory. So you're being overly paranoid about the apps "using your >> >> >> free RAM." If the RAM were low, Android would kick those apps out >> >> >> of >> >> >> memory and free up more RAM, but Android is fundamentally designed >> >> >> to >> >> >> stuff memory full. >> >> >> >> >> >> These aren't "bugs" per se, although (the first two in particular) >> >> >> are >> >> >> definitely design points that could have been changed, the third is >> >> >> more of a misconception about how Android differs from a desktop. >> >> >> >> >> >> By the way, if apps work "secretly" in the background, how do you >> >> >> know >> >> >> they do? The only true way to be in the background and run code is >> >> >> either to: >> >> >> - Start a foreground service, which means you see an icon while >> >> >> that >> >> >> happens. >> >> >> - Start an AlarmManager, which is annoying and shouldn't be done >> >> >> if >> >> >> your app doesn't need it. >> >> >> >> >> >> To make a security policy which says something like "don't work >> >> >> while >> >> >> in the background" you first need to define three things: >> >> >> - What is work, >> >> >> - What is the background, >> >> >> - What is the scheduling policy (when are apps "in the >> >> >> background"?), is it temporally defined, or something else? >> >> >> >> >> >> Kris -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscr...@googlegroups.com. To post to this group, send email to android-security-discuss@googlegroups.com. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/groups/opt_out.
