Related
Running Applications
Hi, im considerably new to the whole android development i have a g1 since early december and have upgrade it to the modded JFC 1.31 ADP. I also have the adp spl i think thats what u call it .
My question relates to the running processes/tasks/programs. I am concerned about the amount of programs that run in the background. Is there a way to cut down on this?
I have already removed Calendar, Amazon, Calculator, Calendar Provider seeing as how i do not intend on using these as for calculator i have installed a scientific calculator.
Its more or less Facebook, Craigslist, Imeem. The other bckg progs Gmail, Messaging, Alarm Clock are all smth i use so therefore i have no issue on that but ive tried editing settings on Craigslist, Facebook, Imeem and others to change the update interval and have maxed those out but still tend to run in the background i use the programs but i dont need them to update themselves.
Edit: I have also stopped the auto sync on Calendar, Gmail, Contacts Seeing as for Calendar i dont need it, Gmail i check it often, Contacts i dont use on my gmail service.
Have you got the task manager app from the app store? Thats what I do, and kill all the apps I don't need active.
TimSykes said:
Have you got the task manager app from the app store? Thats what I do, and kill all the apps I don't need active.
Click to expand...
Click to collapse
Yes i have, however they keep coming back up!
yeah I know some of them do. to me I don't know why alarm does. I don't even have a alarm set on my phone.
They come back due to the way android handles and saves tasks. The OS will keep resurrecting them thinking they are just dormant and were axed by them.
ArronL said:
They come back due to the way android handles and saves tasks. The OS will keep resurrecting them thinking they are just dormant and were axed by them.
Click to expand...
Click to collapse
So is there a way around this or not?
yeah.. im having the same problem, i shut them all down via task manager, but after like 1 minute i go back in there and they all come back up, is there any way to make them be off permanentally till you use them again?
tbh, the way the android works, if it keeps bringing these programs back they're probably not eating up too much memory.
in fact, no matter how much crap is running in the background i've never experienced any lag or anything. makes me wonder if there's any point in killing apps, except for ones that may be constantly connected to the internet.
Meltus said:
tbh, the way the android works, if it keeps bringing these programs back they're probably not eating up too much memory.
in fact, no matter how much crap is running in the background i've never experienced any lag or anything. makes me wonder if there's any point in killing apps, except for ones that may be constantly connected to the internet.
Click to expand...
Click to collapse
Well i definitely notice a lag, although i agree with you on the applications i removed like 80% of them now just using ones i need and just installed the 1.41 everything works great. But run about 10apps let them run in the bckgs and slide the main application tab on the home screen up and down and scroll through the programs. Then kill about all apps but 3 to account for ones you need and try it again you should most likely notice a difference.
Not on lag but background processes use up battery to, I did a wipe and have like four apps on my phone: aim astro any cut and ak notepad (wow must like A's) but my battery life is noticible better than before, I can go a whole day with out having to charge vs having to charge every few hours
does anyone know of a startup manager for the G1 for EG when i reboot or start up my phone i get a lot of services and programs which i use but do not want to start on boot.
i can use task manager to close them once the phone is started but wouldt be happy for something that disables these from the start.
Has anyone found a way to modify what OEM apps boot at startup?
So using Task Manager for Root Users we get this peek into what's ?running? on our phone. or am i sadly confused..
upon initial boot and after letting the phone boot fully (about 3 minutes) i get this list in my taskmanager..
Task Manager ---not oem
Service Viewer ---not oem
MyFaves storage
Messaging
Voice Dialer
Google Talk
Maps
Calendar
Alarm Clock
Power Manager ---not oem
Missed Call ---not oem
Messaging
Phone Recorder ---not oem
MyFaves Storage
Voice Dialer
Google Talk
Maps
The list remains the same even after several refreshes..
...oddly only after killing a few tasks this is added?
Gmail
note: at this point in service viewer/tasks, only taskmanager, launcher and service viewer are present..
After killing every process through multiple refreshes messaging (which I assume is a critical app tied to the notification bar) is the only thing that remains until i load something else..
First question..are the apps listed in task manager actual hurting my battery/memory/cpu performance?
Secone question..Is there any way to auto-kill these tasks upon boot, other than by removing them? Or is there some boot.ini type file that could be editted?
sry for the long post, just curious if something can be done...
Yeah id also like to know how to manipulate what starts up on boot.
Any dev should be able to tell us.
Plenty of apps start at boot.
Seriously I would LOVE the answer to these questions. Thanks
Now while this isn't coming from a dev, when I look at the running app list I often see things I haven't touched, but they won't start unless the phone's been idle. I think what happens is it actively fills empty ram with programs so they will start faster, so I think it's just in the nature of Android.
Fushichou said:
Now while this isn't coming from a dev, when I look at the running app list I often see things I haven't touched, but they won't start unless the phone's been idle. I think what happens is it actively fills empty ram with programs so they will start faster, so I think it's just in the nature of Android.
Click to expand...
Click to collapse
yes but dont they use up cpu/memory/battery? plus i dont think the programs are so resource heavy that they would need a process running.
An answer from a Dev is what we need
I think what we need is an explaination as HOW a program can autostart on boot. If every program on my phone (stored to sd) started automatically when I turned on my phone I'll be waiting a week for it to start up. There has to be a script that these programs add to or something to run these program automatically. Either that or it's the programs themselves that are set up to start up by themselves. Where if that's the case I think we're screwed.
I'm also VERY interested in this.
Also, how to keep apps from auto-restarting once you kill them. PixelPipe has a background service that, once you start the app after reboot, it won't die. Their app support guy states otherwise tho, heh.
Also, I like how the OS says a program has "died"
I wouldn't really worry about it. For one most of those processes will be sleeping. They use no CPU time when they're in this state. Some processes register an event with the kernel and just sleep forever until that event occurs and the kernel reactivates the process. Some processes sleep for a specific amount of time, wake up and do some task, then go back to sleep. In both cases the number of CPU cycles being used are likely negligible. Most of those start-up programs will fall into one or the other category. The stuff that does take up a fair amount of CPU cycles are things like the multimedia system, the UI system, messenging, etc. In other words, the stuff you want to keep running.
Also, I wouldn't pay too much attention to those memory usage numbers. There's heavy use of shared libraries in the system. Ordinarily processes are only allowed to access memory that is allocated to them. This memory is where the process stores the bits that make up its code (stuff that doesn't change) and where it stores its working data (stuff that does change). Its actually more complicated than that but this will suffice for now. Libraries that are not shared are accessible only to the process that is using it and is stored in the memory allocated to it. Libraries that are shared can be used by multiple processes. These shared libraries are allocated to one place in RAM and when an app needs to use one of them the kernel takes care of mapping the location of the library so the app can access it as if it was in its own memory space.
The memory usage numbers you are seeing do not take into account these shared libraries. An app may be using only 1 or 2 MB of RAM but since it uses a shared library the RAM being used to hold the library is also counted and the size could be shown as 20 or 30 MB higher that what it actually is. You could kill a process and recover some memory but its probably not enough to be worth it since more than likely most of the RAM being used was in shared libraries and they'll still be there after the process is gone.
numerik, thanks for the info. But now I guess my bigger concern would have to do with this part:
Some processes sleep for a specific amount of time, wake up and do some task, then go back to sleep.
Click to expand...
Click to collapse
Similar to the problems we run into in windows. Some lame program gets added to msconfig (be it a m$ app or wicked virus), it sits there idle when you fire up your computer uses a minimal amount of cpu amd memory then does who knows what whenever it wants.
At the android-platform group, we've been hashing out a scheme for adding in official apps-to-sd support to AOSP. We have a couple of google engineers following along/helping out and are now at a state where the initial testing implementation (we're using an incremental development approach) steps are defined in a fairly simple manner and we are ready to start at it from an actual implementation details/start coding perspective.
The actual thread is located here: http://groups.google.com/group/android-platform/browse_thread/thread/bf0709c157451cd9
Basically, if implemented, it will do the following;
1) totally obsolete current hacker apps2sd approaches by allowing actual sdcard removal from device.
2) ultimately ship with devices stock (when in a state where it is easy to use, stable, and at least as secure for non-root users as internal storage currently is).
3) keep application data on the same device as the actual application with no side-effects (like internal apps being broken while waiting for second partition to mount).
4) allow MULTIPLE sdcards containing apps to be swapped on the same device.
5) allow sdcard containing apps to be swapped between DIFFERENT devices.
Note: 4 and 5 are not in the initial implementation, first proof of concept and working system, then enhancement with additional features. 4 and 5 are not requirements for inclusion in AOSP, but they are cool features that ultimately should be implemented.
What we need:
Several good developers, web storage w/source/patch management, etc.
Anyone interested, please read the thread to get an idea of the current state of thought, and please don't pollute that thread with nonsense. There is a current state of organization, and though not set in stone, it should be considered as NOT open for major architectural changes (i.e., the google engineers don't have any major problems with the proposal that we can't work through). Minor glitches and implementation details will be handled along the way. If you must pollute a thread with nonsense, use this one.
Really? Nobody AT ALL is interested?
This is the *ONE* major feature missing from AOSP!
Id PM twistedumbrella and cyanogen and shafty
JAC would prolly be interested but hes been busy with personal stuff i guess?
Just keep bumping this thread to keep it at the top. this needs to be done, and is long overdue on android...
It's a must
I'm sorry that I'm not a developer. Good speed!
I really don't think a2sd is a good solution at all (I've been following the discussion at android groups), rather, I believe the lack of an a2sd solution will eventually lead to device manufacturers to increase the amount of internal storage available on the device for applications (this is what this project is all about, isn't it, not enough storage for apps?) like Samsung did with it's Galaxy.
We shouldn't assume that a device is going to be used a particular way because then we'll run into problems. We shouldn't assume that an user will want to have their device used that particular way, be it partitioned or with a custom, secure filesystem stored in the SD. How do we explain that they'll lose some of their sdcard to app storage? If we make it automatic, how do we allow the user to disable it if they do not want it? How do we make it if an user wants to have one SD card with apps on it and another one without them?
Again I believe we should let the demand for more storage drive the evolution for the next android devices instead of just making it work and have manufacturers ignore the real need for increased internal storage.
I disagree with it not being a good solution. Technology is always advancing, but people can't always follow suit with what is the latest. Be it financials or whatever, Having this as an option will allow older hardware to run more efficiently, Bring costs down for manufacturers and give everyone more options.
@Jubeh, All the questions you raised I believe could be addressed, Have a new settings menu and let them choose. If they select it, it will give it pop up saying "x amount of space will be reserved on your SD card for app storage".
And with AOSP, Android is not just a mobile phone os anymore, It is a mobile platform. Imagine if you buy and download apps on your phone, You save them to your SD card because of this suggested add-in. Now you also own a media tablet that runs android, For example something with a bigger screen usually used for movies and gaming, Now if we had this you could put your sd card in that device and have all your apps like that. I think that would be an amazing feature for android.
I can think of big issues being encryption, piracy seems like it would be easy to accomplish with something like this, but again this should still be addressed and at least attempted to make available. It would be a huge step for the android platform. My 2 and a 1/2 cents worth
I dont think its a bad idea at all...
Jubeh while i agree with your ideas, we definitely need to get more on board memory. But things like apps, and even most cache's shouldnt hinder or take up precious phone storage. I mean seriously, are we hoping for gigs in the near future? Probably not, lol. But the apps2sd is something we can and should change now, to help bring on future ideas.
And what about those already locked into their devices, or where purchasing a newer improved version isnt feasable? Its hard to rationalize a new smart phone every year, even though we all do it, lol. But some bought the g1 hoping to not have to purchase a new device for multiple years, dont they deserve some kind of back compatablity as well?
Whether it should or should not be implemented is not open to debate. The objective is to actually IMPLEMENT it -- in a manner that meets the stability and security requirements of AOSP. One way or another, community needs WILL implement this system, problem is that the current implementations are just crazy HACKS --- unstable, unreliable, etc. As someone who WILL be installing applications to sdcard, *I* want the system to actually WORK PROPERLY, and I'm sure that not only most everyone else (with VERY VERY few exceptions...) does.
Also, the fact that anyone (jubeh) would bring up those completely retarded points about "assumptions regarding use cases" proves in no uncertain terms that they didn't read the thread linked to (even if they did make themselves look completely retarded by replying in it).
In other words jubeh: If you don't read before you reply, you will make yourself look like an a$$. Now run along.
Oh, and what did I say about keeping the NONSENSE out of that thread? Really... you need to learn to READ.
lbcoder, I have to hand it to you. You killed your project quicker than anybody else possibly could have. While many users wouldn't necessarily agree with what jubeh said, he was raising what he considered were valid points in a fairly reasonable manner. Instead of pointing out that you had already worked on those points and that you didn't want to rehash them, you trashed him (three times) and made it pretty clear that you would be an a$$ to work with. I wish you luck in finding devs who want to put up with that.
I think either member have the right to say what they please.
While lbcoder was a bit harsh, I can understand his frustration.
They're both senior members however, and have both have contributed MASS amounts to the comunity. If they want to hash out a problem so be it.
All its doing is keeping this thread at the top
sykokenndogg said:
I think either member have the right to say what they please.
While lbcoder was a bit harsh, I can understand his frustration.
They're both senior members however, and have both have contributed MASS amounts to the comunity. If they want to hash out a problem so be it.
All its doing is keeping this thread at the top
Click to expand...
Click to collapse
i agree. this should DEFINITELY stay at the top non-rooted g1 users at the very least should have these a2sd AOSP updates... and everyone else can just get the regular updates because they have enough internal memory
lbcoder said:
the current implementations are just crazy HACKS --- unstable, unreliable, etc.
Click to expand...
Click to collapse
Not to fill this thread with more nonsense but I have to disagree with you on saying the current apps2sds are just crazy hacks. Hacks? yes. Crazy, unstable, and unreliable? No. The new roms that are out currently automatically move your apps to your ext partition on startup if the ext partition is there. If not then the apps will not move there. The fact that you can dual mount your sd now also illiminates any FCs while you have the phone mounted to a pc. I am not saying that the method can not improve but anyone that is currently running an Enom or Cyan rom can tell you if you didnt personally create the partition then you would have no idea that the apps were on the sd.
Agreed, A2SD is stable
If you follow the directions, Apps2SD is more stable than most of the apps on it, imho.
I think the problem that people are having with stability involve the several ways to get there, the fact that each is a multi-step process, and Android users seem to run the gamut from someone who could hack into Sun Microsystem's payroll to someone who just got their first ,uh, smartphone. Most of us tend toward the latter. If you wrest the control from the user and automate it, then I think we'd see the last of A2SD instability.
Internal memory isn't just for apps, and I think it'll grow regardless. People like high numbers on boxes. WM (WP?) has had this since pre-turn of the century, and the demand for more phone memory hasn't decreased. As a matter of fact, the ROMs just grew, and grew, and grew.
Hey, it's cheaper, it's pretty much just as fast, and if it's easy, people will be able to figure out what the different partitions are once they get them and have to manage them, so it'll teach the masses. I'm all for it. Can't code for diddly, but I like the idea.
Yeah. Bump.
Edit: Yes, you will catch more flies with honey. In the friendliest way I can say it, lose the 'tude, or you'll lose out on a lot, lot, lot of other stuff, and you likely won't be able to figure out why things aren't working out for you. You can't really look back and say what might've been, either. You can, and please do, still say what you need to say, maybe even more, but *how* you say it really matters.
a2sd is FAR from being a stable, reliable, sane solution to the device's storage problem, I've said it time and time again.
Being "Senior Member" is in no way a measure of reliability, experience, or knowledge. I could fill 10,000 posts with 4/5ths of them being "Reported 10 chars" and be a senior member. Also, although I've tried to help where I can, I don't think I've yet contributed anything significant, mainly to avoid the barrage of posts afterwards asking how to make it work... and that brings me back to topic; the storage of apps on SD-card would be hell for carrier's support lines. The implementation is mostly non-existent in MASS MARKET headsets, and although you're right to point out that Android is making strides beyond the phone market, I believe the implementation would be shunned by google for several reasons; the formerly mentioned carrier support hell, both carriers and manufacturer's desire for handsets to become obsolete, google's desire to keep android appealing to both carriers and manufacturers, and possible competition in the thin-portable client and netbook spaces against it's own upcoming Chrome OS.
At this point already, the hope that the feature will "2) ultimately ship with devices stock" is pretty, pretty slim.
As opposed to what most members here might think, we're in the minority (rooted Dream users), and although a2sd does cater to some rooted users, we're still talking about the minority of Dream devices out there (since really, it seems the only reason behind implementing a2sd is the Dream's stock 70 MB app storage space, most other devices at least double that amount). Normal people (read: not us geeks) change devices often almost as a fashion statement, so any solution, if it did make it as an update, would be to support the desire of a small fraction of an almost obsolete device.
Besides, even starting with the way apps are currently handled by the device, it would require a major re-working of the platform to get this monstrosity working. Currently, apps are handled in two spaces, system apps, which can't be un-installed, and user apps, which can be un-installed, updated, etc, but not by the user, but by the package-manager. A better solution would be a third app space for sd-card installed apps. The system/package manager would not install these apks downloaded directly to the sd-card's fat32, rather, they would just show up on the app launcher (we could have scans for new apps every time an sd-card was inserted/removed). With donut's on-demand dexopting, we could create another directory in /data, say, /sd-dalvik-cache, or even leave the .dex in the sdcard while the app was in use and remove it when the app stops (and clear any .dex on sd-card mount), and create a third category of apps that could be installed to sd (in lieu of it, apps would get thrown into /data/app and moved back to sd as soon as one was available, of course, after prompting the user). This way, developers would be able to choose for their apps to be installed to SD and they could take the appropriate security measures to ensure the safety of their code, if that's what they want.
A2SD should have been an option for android in first place. Windows mobile has it, why not android? Is it stable and usable the way it is - sure. But what happens if I want to take out my sdcard and put it in a card reader?
It's one of the major failures of android along with it not supporting adhoc
networks, bluetooth obex as default and some other significant issues.
Don't get me wrong here - there are many things I love abut the platform but
flaws are there too. I've had winmo standart, winmo pro and now an android phone and in terms of "getting the job done" all three have their + and -.
The *current* mechanism to install applications on SD is an EXTREMELY hacky piece of junk.
Though it will work, it will only do so under the following conditions;
1) the user is fully aware of the limitations of the system and doesn't do anything that will stress it out,
2) the sdcard is *always* in the device, never removed.
3) it is impossible to use multiple sdcards in the same device.
Let me pose this question to everyone;
WHAT HAPPENS if you are using hack-apps2sd and you remove the sdcard? You know, just PULL IT OUT... This is something that "regular" users do *all the time*.
This is only one of many conditions that need to be managed by an apps2sd system before it can be considered for inclusion in a consumer device.
Needs to be done;
1) The user needs to be able to chose whether or not to enable apps-to-sd and must set itself up on the phone itself by just the click of a button.
2) The user must be able to SWAP SDCARDS at will. This includes the case where they just rip the card out without unmounting it.
3) When an sdcard is inserted containing apps, the system must automatically set it up and add those applications to the package manager.
4) UID collisions must NEVER happen.
5) External apps must be able to be sanely removed from the package manager upon unmount (planned or unplanned).
6) Processes with open file handles must be politely shut down upon a planned unmount.
7) Processes with open file handled must be CLEANLY killed off upon an UNPLANNED unmount.
8) PROTECTED-APPS must be copy protected when stored on the sdcard to at least equal security to that used internally, i.e. they should be encrypted using a randomly generated key stored in a root-only location within /data.
9) The user must be able to chose where to install a new application.
10) Application home directory and dalvik-cache must be stored on the same media as the application is installed to, i.e. internally installed apps should have their home directory and dalvik-cache stored internally, externally installed apps should have their home directory and dalvik-cache stored externally.
11) Optional: Ability to grow/shrink the amount of storage on the sdcard devoted to applications.
In other words, the user experience should be like this;
1) With a regular sdcard inserted (or no sdcard inserted), the user experience must not be any different than it is currently.
2) User can go to Settings-->SD card & phone storage-->(SD card) Enable application install to SD card. This prompts the user for how much space to devote to applications (default, say equal to internal), and then sets it up.
2B) optional -- user can go to Settings-->SD card & phone storage-->(SD card) "Change SD card space reserved for applications". Prompts for new size (min size = current space used, max size = current available + total sdcard available).
3) User goes to install a new app, if the card has application storage enabled, the installer asks where to install the application to (internal or sdcard).
4) User safely unmounts sdcard -- if applications are running, prompt "There are applications running on the sdcard (list them), these will be terminated. Continue?", terminates applications, removes them from package manager, unmounts.
5) User unsafely pulls sdcard -- if applications were running, message "These applications were running on the sdcard. They have been terminated and any unsaved data has been lost."
6) User inserts or mounts sdcard, system scans if application install is enabled on the card, if it is, the applications are added to package manager.
discussion management
lbcoder,
The thread at groups.google is definitely the technical thread, so I am using this one to comment on your reply dated Oct 30 2:39 pm.
Hands down I believe that for the sake of keeping the discussion open (one of the pillars of the scientific method) is to allow comments that may or may not agree with your or anyone else's point of view.
I agree on that Armando's idea is wrong, just like you do. Although he does have some valid points, which anyone who reads carefully can see. He is probably out of line writing what he did on the technical thread instead of here; and should be scolded for that. But not for sharing his thoughts. I won't elaborate on my own ideas on the matter this because it is not my purpose with this post.
My purpose is to ask everyone working on both this and the technical thread to tone it down, please. XDA sometimes becomes a battleground, sometimes funny and sometimes wasteful and even annoying and both this and the technical thread at groups.google could be very valuable for the platform.
BTW: I'm a well seasoned developer, with well over 15 yrs of experience and who leads reasonably big projects.
Thanks for the thread. It is well worth it, whatever the outcome is.
fosormic said:
lbcoder,
The thread at groups.google is definitely the technical thread, so I am using this one to comment on your reply dated Oct 30 2:39 pm.
Hands down I believe that for the sake of keeping the discussion open (one of the pillars of the scientific method) is to allow comments that may or may not agree with your or anyone else's point of view.
I agree on that Armando's idea is wrong, just like you do. Although he does have some valid points, which anyone who reads carefully can see. He is probably out of line writing what he did on the technical thread instead of here; and should be scolded for that. But not for sharing his thoughts. I won't elaborate on my own ideas on the matter this because it is not my purpose with this post.
My purpose is to ask everyone working on both this and the technical thread to tone it down, please. XDA sometimes becomes a battleground, sometimes funny and sometimes wasteful and even annoying and both this and the technical thread at groups.google could be very valuable for the platform.
BTW: I'm a well seasoned developer, with well over 15 yrs of experience and who leads reasonably big projects.
Thanks for the thread. It is well worth it, whatever the outcome is.
Click to expand...
Click to collapse
There is no place in this discussion for opinions. Its not about battling, its not about opinions, its not about any of that BS. What I am asking is for anyone INTERESTED in CONTRIBUTING (either in code, or in rational discussion regarding implementation details) to come forward and do so. Everything else is irrelevant and out of place.
As for his having valid points... not relevant since ALL of his valid points have been addressed. His purpose (if he has any at all) is therefore simply to disrupt progress.
And since he has effectively destroyed this thread with his nonsense, I may cease monitoring this thread. Anyone interested in contributing, please contact me by PM. Anyone interested in being disruptive, don't waste your time -- really, just go away.
lbcoder said:
The *current* mechanism to install applications on SD is an EXTREMELY hacky piece of junk.
Though it will work, it will only do so under the following conditions;
1) the user is fully aware of the limitations of the system and doesn't do anything that will stress it out,
2) the sdcard is *always* in the device, never removed.
3) it is impossible to use multiple sdcards in the same device.
Let me pose this question to everyone;
WHAT HAPPENS if you are using hack-apps2sd and you remove the sdcard? You know, just PULL IT OUT... This is something that "regular" users do *all the time*.
This is only one of many conditions that need to be managed by an apps2sd system before it can be considered for inclusion in a consumer device.
Needs to be done;
1) The user needs to be able to chose whether or not to enable apps-to-sd and must set itself up on the phone itself by just the click of a button.
2) The user must be able to SWAP SDCARDS at will. This includes the case where they just rip the card out without unmounting it.
3) When an sdcard is inserted containing apps, the system must automatically set it up and add those applications to the package manager.
4) UID collisions must NEVER happen.
5) External apps must be able to be sanely removed from the package manager upon unmount (planned or unplanned).
6) Processes with open file handles must be politely shut down upon a planned unmount.
7) Processes with open file handled must be CLEANLY killed off upon an UNPLANNED unmount.
8) PROTECTED-APPS must be copy protected when stored on the sdcard to at least equal security to that used internally, i.e. they should be encrypted using a randomly generated key stored in a root-only location within /data.
9) The user must be able to chose where to install a new application.
10) Application home directory and dalvik-cache must be stored on the same media as the application is installed to, i.e. internally installed apps should have their home directory and dalvik-cache stored internally, externally installed apps should have their home directory and dalvik-cache stored externally.
11) Optional: Ability to grow/shrink the amount of storage on the sdcard devoted to applications.
In other words, the user experience should be like this;
1) With a regular sdcard inserted (or no sdcard inserted), the user experience must not be any different than it is currently.
2) User can go to Settings-->SD card & phone storage-->(SD card) Enable application install to SD card. This prompts the user for how much space to devote to applications (default, say equal to internal), and then sets it up.
2B) optional -- user can go to Settings-->SD card & phone storage-->(SD card) "Change SD card space reserved for applications". Prompts for new size (min size = current space used, max size = current available + total sdcard available).
3) User goes to install a new app, if the card has application storage enabled, the installer asks where to install the application to (internal or sdcard).
4) User safely unmounts sdcard -- if applications are running, prompt "There are applications running on the sdcard (list them), these will be terminated. Continue?", terminates applications, removes them from package manager, unmounts.
5) User unsafely pulls sdcard -- if applications were running, message "These applications were running on the sdcard. They have been terminated and any unsaved data has been lost."
6) User inserts or mounts sdcard, system scans if application install is enabled on the card, if it is, the applications are added to package manager.
Click to expand...
Click to collapse
well the extremely hacky piece of junk took a lot of hard work from the developers here......show some respect
Update 03/08/11
NotEnoughSpace has finally graduated to the Android Marketplace!
Beta testers can currently get it at its "thank you" price of $0.99.
I will set the regular price in a week so hurry
*** *** *** ***
Note #1: your phone needs to be ROOTED to use this application.
Note #2: so far, only tested on Droid Incredible and HTC Desire.
From the built-in help:
About this application
This application's goal is to help you understand and possibly work around a common vexation of using Android; i.e. these messages:
"not enough space"
"Low on space. Application data space is low."
What is happening?
You've checked your phone's vitals and it appears that it has plenty of space left, both internal storage and SD Card storage. So, what's happening?
Android allows your applications to store their data, primarily, in a dedicated partition whose size happens to be much smaller than even the phone's internal storage space. Generally south of 150 MBs.
This is the partition that fills up so quickly and that Android has been complaining about.
And the help goes on and on so I'll stop here.
The short version
Using this application, you can see which applications use up most of your phone's data space and decide what to do with them.
You can also move the biggest directories to the phone's SD Card.
Additionally, you can use the app to cleanup the Dalvik cache but it's not the app's primary function.
Please, help test it!
I will gladly welcome any constructive criticism; I expect most of it to be along the lines of "The tool is not quite accurate" and that's what I wish to address first.
To create a debug report (these are very important):
Simply select the "Debug" menu and follow the on-screen instructions.
The whole email business is so that you can copy/paste from a desktop client.
The .apk can be downloaded from nexus.zteo.com/projects/beta/
Update 12/04/10
The application should now display correct stats for phones/ROMs that use Busybox. If you have already tested it and it said "NaN" please try it again.
This should be interesting, maybe kinda Android GpartED?
cyansmoker said:
Using this application, you can see which applications use up most of your phone's data space and decide what to do with them.
You can also move the biggest directories to the phone's SD Card.
Click to expand...
Click to collapse
Curious, does this mean you can move and symlink data, or are you talking about Froyo Apps2SD?
teorouge said:
This should be interesting, maybe kinda Android GpartED?
Click to expand...
Click to collapse
Obviously not, he's managing what's there, he's not partitioning anything.. Did you read?
khaytsus said:
Obviously not, he's managing what's there, he's not partitioning anything.. Did you read?
Click to expand...
Click to collapse
Come on, what's the matter dude? I did read, and from what I read I thought whole partition handling was the only thing this app would be missing. Single files is a good start, but making that "kinda GpartED" would be killer. Though I fear you should be in bootloader/recovery to work on those, don't know how Android deals with them (i.e. in Windows you have programs you can change partitions size "on the fly" with). Now that I elaborated more, are you still angry?
This application would be genius. I'm wondering however, will the phone still be able to access that data once it is moved off of the system memory and onto the SD Card? And is it possible to actually partition the /data/data section so that it will use more than the allowed 150mb that it has, like open it up so that instead of it being partitioned to a small amount, it just roams free with the rest of the 748mb or whatever that is in the system memory.
A promising app, thanks.
Navigon, however, doesn't like its data to be moved to SD card. Even after moving it back with the app, it FCs (Android 2.1). I think I have to reinstall. So be careful if you're trying to do the same.
Edit: After reinstalling the .apk (without doing anything with the maps), Navigon works again. The packet installer didn't ask me if I wanted to replace the existing installation (as is otherwise usual in such a case).
Edit2: There seems to be a general problem. The next app I tried was mediaU. It has a large database which I moved (using NES) to the SD card. It also FCed after having moved its database, and restoring to the old location (again using NES) also didn't succeed. No error message during restore, but app still won't run.
Phone: Galaxy 3, Android 2.1 (original ROM).
mizch said:
A promising app, thanks.
Navigon, however, doesn't like its data to be moved to SD card. Even after moving it back with the app, it FCs (Android 2.1). I think I have to reinstall. So be careful if you're trying to do the same.
Edit: After reinstalling the .apk (without doing anything with the maps), Navigon works again. The packet installer didn't ask me if I wanted to replace the existing installation (as is otherwise usual in such a case).
Edit2: There seems to be a general problem. The next app I tried was mediaU. It has a large database which I moved (using NES) to the SD card. It also FCed after having moved its database, and restoring to the old location (again using NES) also didn't succeed. No error message during restore, but app still won't run.
Phone: Galaxy 3, Android 2.1 (original ROM).
Click to expand...
Click to collapse
Tonight I'm gonna try for sure and report back, this does look promising! Did you succeed with some apps?
teorouge said:
Did you succeed with some apps?
Click to expand...
Click to collapse
K9 seemed to work. However, I had to reflash for another reason, and now K9 reports its lib as being in the standard location (reported by NES). For now, I have stopped testing NotEnoughSpace so I can not say more.
mizch said:
K9 seemed to work. However, I had to reflash for another reason, and now K9 reports its lib as being in the standard location (reported by NES). For now, I have stopped testing NotEnoughSpace so I can not say more.
Click to expand...
Click to collapse
eh? K9 has native use of the SD card if you enable it... Why would you use this on it?
Thanks for doing this testing, guys.
I will install these apps and test them myself.
teorouge: you moved the database/ directory, is that it?
mizch: so, you re-installed K9 after reflashing, right?
Everybody: what about the "free space" numbers reported by the app? Do they seem correct to you? I had to use a dedicated algo to compute them, taking block size in account, and I've had reports of fairly surprising discrepancies.
Free space doesn't seem to update after moving, though I see the difference in the Titanium Backup count: tried for a couple of apps (G Earth and well... don't remember!) and it did move everything, free up space on /data and I can still use those apps. Still afraid to move many apps, just moving one at the time and test.
I just tested it out on my Droid 1, which is running CM6.1RC5 (Not sure if thats relevant or not), and it doesnt seem to work very well on my phone. All apps came back as 4KB, at the top it showed this... Total:261.8MB Used:NaNKB Free: 259.1MB Database NaNKB Files: NaNKB Preferences:NaNKB Cache:NaNKB.
Heres the debug report: 1:/dev/block/mtdblock6 268032 224572 43460 84% /data
2:62855 /data/data
3:4096/0/265352
Sorry - never mind; found the info in FAQ.txt after downloading
cyansmoker said:
Note #1: your phone needs to be ROOTED to use this application.
Note #2: so far, only tested on Droid Incredible and HTC Desire.
From the built-in help:
About this application
This application's goal is to help you understand and possibly work around a common vexation of using Android; i.e. these messages:
"not enough space"
"Low on space. Application data space is low."
What is happening?
You've checked your phone's vitals and it appears that it has plenty of space left, both internal storage and SD Card storage. So, what's happening?
Android allows your applications to store their data, primarily, in a dedicated partition whose size happens to be much smaller than even the phone's internal storage space. Generally south of 150 MBs.
This is the partition that fills up so quickly and that Android has been complaining about.
And the help goes on and on so I'll stop here.
The short version
Using this application, you can see which applications use up most of your phone's data space and decide what to do with them.
You can also move the biggest directories to the phone's SD Card.
Additionally, you can use the app to cleanup the Dalvik cache but it's not the app's primary function.
Please, help test it!
I will gladly welcome any constructive criticism; I expect most of it to be along the lines of "The tool is not quite accurate" and that's what I wish to address first.
To create a debug report:
Simply select the "Debug" menu and follow the on-screen instructions.
The whole email business is so that you can copy/paste from a desktop client.
The .apk can be downloaded from nexus.zteo.com/projects/beta/
Click to expand...
Click to collapse
Do you have more details about this program anywhere? I went to the download page but see no further info...
Help Section Typo
Under A Quick user guide in your user guide(?) that prompts when you run the apk for the first time there is a typo in the last sentence:
You can touch any application to explore its content and figure out what is taking up some much space.
Click to expand...
Click to collapse
So far I havent run into any issues with the apk...
Not to burst anyones bubble, but Choose Install Location has been doing this in a comprehensive way for weeks. http://www.appbrain.com/app/choose-install-location-free/com.beidl.chooseloc
Free Memory?
bdt1995 said:
I just tested it out on my Droid 1, which is running CM6.1RC5 (Not sure if thats relevant or not), and it doesnt seem to work very well on my phone. All apps came back as 4KB, at the top it showed this... Total:261.8MB Used:NaNKB Free: 259.1MB Database NaNKB Files: NaNKB Preferences:NaNKB Cache:NaNKB.
Click to expand...
Click to collapse
I'm having the same problem as bdt1995. Running CM 6.1 RC1.. the only difference is the total memory is 196.2 and the free is:194.3 MB cuz I'm using a Nexus.. CM6 might be the problem?
bdt1995 said:
I just tested it out on my Droid 1, which is running CM6.1RC5 (Not sure if thats relevant or not), and it doesnt seem to work very well on my phone. All apps came back as 4KB, at the top it showed this... Total:261.8MB Used:NaNKB Free: 259.1MB Database NaNKB Files: NaNKB Preferences:NaNKB Cache:NaNKB.
Heres the debug report: 1:/dev/block/mtdblock6 268032 224572 43460 84% /data
2:62855 /data/data
3:4096/0/265352
Click to expand...
Click to collapse
Same here (total 196.2MB, Free 194.3MB, all apps 4KB), system details in my sig. Using apps2sdext, over 200 apps.
Debug info:
Code:
1:/dev/block/mtdblock5 200960 112144 88816 56% /data
2:96070 /data/data
3:4096/0/198951
Same problem as above with Cyanogen 6.02, However it looks promising.
I Think that moving data to standard SD can leads to security issue, because SD can be readed and written by any apps. Should be better if the app recognize /EXT partition, if exist, and move data here.
i'd like to try it and i get my lil sis to try it also she gets this problem a lot i have the droid incredible and my sis has the droid eris.
bdt1995, rnh16, britoso, mmorselli:
Thanks for the debug info. Indeed Cyanogen is a tad "exotic" for NES at this point.
Please download the latest version of NES -- I just uploaded it. It contains an extra debug line which should allow me to make it work so please paste your debug output here one more time.
JerseyFF:
Oops, thanks.
lhinsz:
Because it is a beta version, it hasn't been released yet and all the information you may need is contained in the Help screen. I tried to make it comprehensive.
BigNate:
Should work with HTC devices, yes. Could you or you sister paste her phone's debug screen here?
Zandog:
I do not think that both apps share the same goal so no lives should be lost (Seriously, not much of a bubble to burst?)
INTRODUCTION
This is a guide made to with help from Xperia X10 users and developers for Xperia X10 users enjoyment but most of the tips contained here are suitable for any phone running Android. The tips contained here focus on WHAT to do to improve the performance of your phone and not HOW to do it, after all, once you know what must be done is to find simple tutorials on how to take these actions.
For some of the tips contained in this guide I assumed that you have just installed a new ROM or formatted / bought your phone recently and have root access but even without these prerequisites this guide can still be useful to most users.
It’s important to say that although most of the tips some are quite basic, some require a little more work and deal with the more delicate parts of your phone, they should be made at your own risk. These more advanced tips often use very specific terminology which you can find more about on XDA Developers or even Google.
Finally I would like to remind that even machines that are made within a few standards can operate in different ways: some phones take better advantage of certain adjustments and settings and not others so it’s impossible to guarantee one hundred percent efficiency for all of you but still I that you make good use of this guide.
Sincerely,
Guilherme "XOT" Oliveira
- Install a good ROM and a good Kernel
Official ROMs are good but custom ROMs are usually faster and in many cases as stable as official ROMs. This is because ROMs are released and thereafter rarely change, custom ROMs are already made by developers who are constantly improving their job to get the most out of your phone. It's very important to research before installing a new ROM, searching always for the one that meets your expectations and relates well with your device since the same ROM can work very well on my x10 but not as well on x10 my brother’s for example.
The same goes for Kernels, but with Kernels take extra care to make sure that the Kernel is compatible with your desired ROM and your phone.
- Keep clean your caches
Caches are good to keep certain information and have access to these faster but with these files and information some "garbage" is stored .
The solutions to this can be pretty basic or advanced, the most basic way is to enter your Application Manager (Settings> Applications> Manage Applications) and clear the cache for each application. It is important to clear the cache only and not application data as these may be important such as the files that resemble your progress in a game. Already the most advanced solution is to clear the Dalvik Cache and Cache Partition through your recovery.
Both solutions don’t need to be made with daily frequency, for example I usually clean my caches every 45 days or when I feel that the phone is getting slow.
- Make a full, but clean, backup
Full backups (full system backup) like those made by recovery or nandroid are great to store complete setups but when they are done with “dirty” files in the the phone’s memory restoring these files may worsen rather than help the situation of your device .
Ideally, do a full backup after completely configure your phone (configure your account, set your homescreens, install the required applications, etc.) but before using it for real.
That way if your phone starts getting slow and nothing works to reverse the situation you can easily go back to your “original” settings without the hassle of customizing everything in its way again.
- Do not touch the CPU / GPU the first day
Like people, phones also take a while to adapt to a new environment, or in our case new ROMs, so during the first 24 hours of use is important to use the settings of CPU and GPU that came with the ROM, no overclock, undervolt and things like that.
Another important step in the process of adaptation to the new ROM is really using and exploring the device in this very first day so it "get used" to the change. Do not mind the battery consumption, that should stabilize after a few days.
It’s also iimportant to remember that some ROMs already comes with overclock, undervolt and improvements in battery usage. In this case there is no problem in using these settings from the first minute because if they are there since the installation of the ROM, it is because they are part of the default settings already programmed and develop on this particular ROM and it will work better this way.
- Use the maximum your battery
Batteries seem to last less and less as time goes on, in part this is because your battery is uncalibrated and there are ways to fix it.
I will not talk much on this subject because it is very easy to find guides that teach you how to calibrate your battery so I’ll just recommend that you take a look at them.
- Applications: less is more
Having millions of apps is the glory and the doom of smartphones, the glory because you can do everything on your device and doom because of the following reasons:
As a computer your phone also slows down the as it becomes full and in most cases you can blame it on the number of apps that you have installed on it. So try to leave installed only the applications you actually use and uninstall the ones that you no longer use so you can have more free memory and consequently a faster device.
Some applications can not be uninstalled because they are system applications; in order to remove those apps you are going to need uninstallers that have root access (ex: RootUninstaller) which are capable of removing these applications but before taking such a measure is necessary to look for a safelist (a list of applications that can be removed without causing system problems).
Keeping a low number of applications but doing so by installing and uninstalling new apps every day also usually let the machine slower so if you find an application for a specific function that fits your needs you should stay with it instead of testing another 10 before returning to it.
PS: A good way to avoid testing several applications before finding the right one is reading reviews and comments before making your choice.
- Repair defective applications
Often the phone is working fine but a certain application or function is not, which can cause slowdowns and FCs (force close); depending on the situation there is not much to do but some of these solutions may take care of the problem:
The first thing to do is to uninstall and reinstall the apps via Play Store to make sure that the problem was not caused by a corrupted file when you downloaded the application, if the problem persists there are some more advanced alternatives: in the advanced settings of your recovery select fix permissions, this function should make sure that every application has the necessary permissions to work properly.
- Keep some free space
Full memory is often a problem on any device, especially in older phones like ours, after all the more files the longer it takes read all these files if it is necessary, so the tip is this: the more free space the better.
This step seems a little redundant since we already talked about having the smallest possible number of applications but this time we are also talking about other files. Anything occupying space on your phone is "bad"; too many photos, songs, text documents, etc.. can make the phone slower and lets be honest, you do not need to carry 150 photos of your last weekend with you all the time.
A solution to this problem is simple, try to keep the memory of your phone as free as possible by eliminating caches, unused files and moving applications to the SD card (Settings> Applications> Manage Applications> choose the application and select Move to SD card or use apps like Link2SD); your SD card should also be kept clean by eliminating unused files and traces left by already uninstalled applications, such traces are sometimes hard to find and applications like SD Maid can help you eliminate much of this "junk".
- Avoid keeping some applications running all the time
It’s very common to close an application and assume that it stopped running on the system but this is not always the case because it actually still cached in the memory of the device, Android makes it to be faster on reopening it later and often the system itself definitively closes the application automatically but that’s not always the case.
Firstly it is important to prevent certain applications from even opening and to do this we use apps known as Startup Managers, there are several options in the Play Store but I particularly like Autostarts. Once inside your Startup Manager you can choose which applications will be opened as the system is started or any action is taken (for example changing the state of your Wi-Fi); the ideal is to minimize the number of self-starting applications, leaving only the truly necessary ones without forgetting to be very careful to avoid stopping system applications because if they are unable to open themselves it can cause instability. Another way to prevent applications from opening or stay on cache all the time is to disable automatic updates of apps such as email clients and social networks but this is a more personal matter that varies from user to user, just remember that the more constant the updates are, the more time these applications will be running in the background and more power (CPU and battery) will be consumed.
Now that we’ve already took care of the self opening apps it’s time to find out when you really need an app to be closed for sure.
It's easy to know when to quit an application completely but it is necessary to first understand a basic concept about the system: applications and processes cached in memory are not always a bad thing, in fact as stated at the beginning of the topic they are a good thing because the application should open faster when launched again (hence the use of Task Killers usually worsens more than help if not done properly) but if you use an application to view the weather every morning and will only use it again the next morning this application can be closed without problems.
In our current official version of Android (2.3) already have a task manager that can be used to do this action (Settings> Applications> Running services > select the desired process and press Stop) but if you want a more advanced option there are several Task Managers that monitor processes and can be used to close them too.
PS: Again about the Task Killers: although its use is discouraged for the day-to-day because of the reasons already explained, if you plan on haevy gaming they can be the great saviors since these games need a lot of free memory to run without lags.
- SMS: clean your inbox
Message apps, both native and third-party tend to take quite some time to open if you have many messages on your mobile because everytime you run your message app it needs to load a large list of conversations, so cleaning your inbox periodically helps performance, the same goes for call log.
A tip for those who want to clear the messages inbox and call log without losing your information is backing up with applications like SMS BackUp + that emails you both your conversations and call logs, all within a specific marker so they won’t end up messing the inbox of your email or if your intention is to save only one or two most important message the native client and most ones available at Play Store have the option of forwarding SMS, simply by holding your finger over until the action menu opens up.
- Give your device a break
Like conventional systems for computers, Android also collects information in its memory and despite the “dumping information system” some of it is left in cache , which ends up requiring more processing on your device.
To end this there is a very simple solution: give a rest to the phone. Once a day or when you feel like the machine is running slow give it a reboot or shut down and leave it off for a minute or two before restarting, it should get rid of the cache and it can boost the speed of the phone, but attention: restart the machine and making it open up various apps on boot has no point so keep your boot clean (see related topic).
- About some specific applications:
Task killers (that goes for any app of this kind) are good for a heavy gaming experience (eg: GTA, Dead Space, Asphalt...) because those games need a lot of free RAM but for everyday use is preferable to don't use task killers and keep some of the apps in the cache so they open faster when they are requested again.
Deep sleep is an important part of the ROM performance when it comes to battery usage, applications like CPU Spy can check if this function is working correctly or No-frills CPU Control which in addition to monitoring provides the ability to adjust the frequencies and governors you want to use in your phone.
Chainfire3D is an useful app to change the way your GPU will work and customize it to gain performance or quality , notice that these values tend to be inversely proportional.
Try always to use the lightest possible applications, it helps in memory. I for one think the galleries and music players of almost all default ROMs are too heavy and prefer apps like QuikPic and UberMusic.
Finally I would like to thank: XDA Users: Oodie, x10forevers, Vasishta Reddy, DiKeJ, 9Lukas5, FeraVolt, alzbac, Websites: lifehacker.com, limitlessdroid.com , doctor-android.com, androidcentral.com for helping with the tips on this guide and say that if you have a tip that is not in this guide feel free to share with us!
PS: I'm sorry if I made some grammar mistakes, English is not my first language and this is a pretty big article.
thanks...nice one..
Dude I screwed my music thing on x10 . Please help . Tried flashing xperia s music player . Now music icon has dissapeared . N power button seem to reboot all the time . Will updating binary files of xrec n then flashing again help ?
Please tel . Desperately.
Rooted x10 2.3.3 stock Rom
Sent from my X10i using xda premium
theMoiz94 said:
Dude I screwed my music thing on x10 . Please help . Tried flashing xperia s music player . Now music icon has dissapeared . N power button seem to reboot all the time . Will updating binary files of xrec n then flashing again help ?
Please tel . Desperately.
Rooted x10 2.3.3 stock Rom
Sent from my X10i using xda premium
Click to expand...
Click to collapse
Hey dude, I don't really know how to help you because I haven't had any similar problems but I'm pretty sure that you should try the basics: clear caches (dalvik included) and fix permissions.
Since I'm not a developer I can't really help you with the binary files but try reaching your ROM's developer and he might help you
I hope you get your phone fixed
Dude u sure that I should clear off dalvik cache ? I tried fixing permission but still nothing . The power button rebooting the phone is more irritating than not having a default music PLAYER . Im asking in this forum but havent got the solution yet :'(
Sent from my X10i using xda premium
Excellent post Buddy . Hope you update the thread with other power users opinions & Tips .
Thanks.
Oodie.
theMoiz94 said:
Dude u sure that I should clear off dalvik cache ? I tried fixing permission but still nothing . The power button rebooting the phone is more irritating than not having a default music PLAYER . Im asking in this forum but havent got the solution yet :'(
Sent from my X10i using xda premium
Click to expand...
Click to collapse
I think that the only people that can help you are the ones on your device's specific forum man, try creating a topic there
Sorry but I really don't know what to do to fix your phone
Some of the tips are a complete waste of time and utter crap (mostly those related to keeping RAM usage low and task killers [EDIT: actually, you contradict yourself on these points], giving the device time to "adapt" to the environment -seriously?- and going for the lighter apps -this obviously applies if you have an outdated device, but it's not a rule).
EDIT: Forgot to say that the rest is good.
GermainZ said:
Some of the tips are a complete waste of time and utter crap (mostly those related to keeping RAM usage low and task killers [EDIT: actually, you contradict yourself on these points], giving the device time to "adapt" to the environment -seriously?- and going for the lighter apps -this obviously applies if you have an outdated device, but it's not a rule).
EDIT: Forgot to say that the rest is good.
Click to expand...
Click to collapse
As I said the guide was wrote based on Xperia X10 user experience so it is kind of an old device.
About the RAM management you won't have any issues with a top device with a lot of free RAM but in our case (old device users) we have about 256mb or less RAM to work with so keeping it well managed is essential if you want your device to run smooth.
The adaptation thing seems like BS but it's not, because your device need to create/edit some files as its being used and that's what this part of the article really means. For example your battery writes a log about its own capacities (making a long story short by recalibrating your battery all you do basically is reset this log)
Thanks for the feedback, hope you found something usefull
GuilhermeXOT said:
As I said the guide was wrote based on Xperia X10 user experience so it is kind of an old device.
About the RAM management you won't have any issues with a top device with a lot of free RAM but in our case (old device users) we have about 256mb or less RAM to work with so keeping it well managed is essential if you want your device to run smooth.
Click to expand...
Click to collapse
No, it's not essential. It's actually bad.
The lifehacker website seems to be down, so I'm giving you a link to this article instead (the article itself links to three more detailed articles; one of them is the lifehacker article I wanted to link; do read them): http://androidandme.com/2011/11/app...lers-still-dont-give-you-better-battery-life/
EDIT: Regarding the battery, draining the battery (to 0% or close) is actually bad for lithium based batteries and should be avoided. A discharge to 15% is usually enough.
GermainZ said:
No, it's not essential. It's actually bad.
The lifehacker website seems to be down, so I'm giving you a link to this article instead (the article itself links to three more detailed articles; one of them is the lifehacker article I wanted to link; do read them): http://androidandme.com/2011/11/app...lers-still-dont-give-you-better-battery-life/
EDIT: Regarding the battery, draining the battery (to 0% or close) is actually bad for lithium based batteries and should be avoided. A discharge to 15% is usually enough.
Click to expand...
Click to collapse
I get your point and I also talk about the same thing as the article in the guide: "the use of Task Killers usually worsens more than help if not done properly" , I just didn't elaborated on this very much.
Now, what I'm saying is that if you are a day-to-day user you don't need a task killer and it's recommended ONLY for a gaming experience, aka heavy games like GTA, Dead Space, etc...
"Task killers (that goes for any app of this kind) are good for a gaming experience but for everyday use is preferable to keep some of the apps in the cache so they open faster when they are requested again."
I'm not a task killer fan myself but if you check any gaming rom (DikeJ's for x10 is a good example) you can see that the developers try to maximize the free RAM because those heavy games use a lot of it.
So in order to avoid this kind of confusion I'll edit the article to solve this misunderstanding thx for the heads up
GuilhermeXOT said:
I get your point and I also talk about the same thing as the article in the guide: "the use of Task Killers usually worsens more than help if not done properly" , I just didn't elaborated on this very much.
Now, what I'm saying is that if you are a day-to-day user you don't need a task killer and it's recommended ONLY for a gaming experience, aka heavy games like GTA, Dead Space, etc...
"Task killers (that goes for any app of this kind) are good for a gaming experience but for everyday use is preferable to keep some of the apps in the cache so they open faster when they are requested again."
I'm not a task killer fan myself but if you check any gaming rom (DikeJ's for x10 is a good example) you can see that the developers try to maximize the free RAM because those heavy games use a lot of it.
So in order to avoid this kind of confusion I'll edit the article to solve this misunderstanding thx for the heads up
Click to expand...
Click to collapse
Cool, thanks for that
Buddy, that guide is awesome written, excellent work. And big thanks for credits - I'm very proud that I could help in that "project" ^^. It's should hit XDA Blog . Cheers .
DiKeJ said:
Buddy, that guide is awesome written, excellent work. And big thanks for credits - I'm very proud that I could help in that "project" ^^. It's should hit XDA Blog . Cheers .
Click to expand...
Click to collapse
I'm the one who have to thank you
People please share your ideas so we can make this guide better!
So of course as many do when rooting want to remove unused system apps to free up storage and memory. I just rooted my Nexus 5 for first time after side loading 5.1. So now I would like to uninstall a few things but have some questions. First off the main things I want to take off are...
Google Hindi Input
Google Korean Input
Google Pinyin Input
iWnn IME
That's it for now but that alone frees up around 100mb. So that is precious space for me since I only have 16gb Nexus. I already have titanium back up installed and es file explorer with root access. With all that into consideration my questions are as follows
1.) Will uninstalling those 4 prevent those languages from being able to be translated in chrome? Or does Chrome control that?
2.) Since they are just languages I assume they will have no effect on system functionality other than not being able to type those languages, correct?
3.) Most importantly will removing those effect any future updates when I have to flash a system update? I'm guessing not but just want to make sure.
4.) Lastly are there any other apps others recommend uninstalling that are not vital system apps? I was also thinking about uninstalling the email exchange and email apps. But really worried that would effect the system if other parts of the system rely on those.
I tried searching for a thread on this and found one from over a year ago but did not want reserect one that old. It also didn't answer these specific questions was mostly about what apps others have uninstalled on their phones.
AndroidPurity said:
1.) Will uninstalling those 4 prevent those languages from being able to be translated in chrome? Or does Chrome control that?
2.) Since they are just languages I assume they will have no effect on system functionality other than not being able to type those languages, correct?
3.) Most importantly will removing those effect any future updates when I have to flash a system update? I'm guessing not but just want to make sure.
4.) Lastly are there any other apps others recommend uninstalling that are not vital system apps? I was also thinking about uninstalling the email exchange and email apps. But really worried that would effect the system if other parts of the system rely on those.
Click to expand...
Click to collapse
1. You are not uninstalling a language, you are remove the keyboard used to input it
2. Yes, you just will not be able to type with them
3. If you use the silly OTA method, yes, as they changed the script to check the sum of the entire partition rather than individual parts. The recommended update method now is to simply flash system.img, boot.img, cache.img, radio.img and bootloader.img (skip userdata.img unless you want to wipe data), as it wouldn't check the partition.
4. You can remove those if you wish.
Thanks! I am going for it now. It is going to feel good with that extra space.
Sent from my Nexus 5
Keep in mind that the space freed by deleting system files can only be used for other system files. The size of the /system partition doesn't change with the size of the rom..
AndroidPurity said:
Thanks! I am going for it now. It is going to feel good with that extra space.
Click to expand...
Click to collapse
That extra space has nothing to do with your 16GB storage. The system partition isn't located on storage, but the data is. So best off all is to use all system. You can do it with make some apps (like Google Messenger) system ones.
Though for now, i still didn't figure it out, how to integrate system apps updates.
To save space odex as many apps as you can and move to system. As the post above says the system space is ringfenced and is seperate. I've taken out google launcher, keyboard etc and put nova etc in the system part. That does save space as does odexing apps.
zerosum0 said:
To save space odex as many apps as you can and move to system. As the post above says the system space is ringfenced and is seperate. I've taken out google launcher, keyboard etc and put nova etc in the system part. That does save space as does odexing apps.
Click to expand...
Click to collapse
You don't need to odex them. You have just to create folder in /system/app and move .apk there.