Related
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
I'm no developer, scripter, or any type of person with a thorough understanding of software but I will try to offer a suggestion to those who wish to give me the time of day.
After flashing countless ROMs looking for the fastest and most simple platform to use everyday I have discovered a few things that might help if people agree with me or not. After loading every ROM and first booting... I realize that Advanced Task Manager shows the available system memory at less than half and i haven't even started running apps or installing programs yet. Processes start when the phone boots up that are running in background (asleep but still using system resources) and i believe that a fair percentage of them are not required by the everyday user.
Why is Alarm Clock running in the background when i haven't started it? Why is Email client running and i haven't setup exchange or an email account? Messaging, Maps, Settings, Gallery, these all start up without being physically executed and are using resources. If there is a reason for them to be there like not being able to receive SMS if Messaging is not running, then that is fine and im an idiot... But if there is no need to startup the application from boot then why do it?
My second point is when packages are installed as the ROM is flashed, they cant be uninstalled right? well what if we didnt want tethering apps and facebook apps and proprietary software (Moto apps)? Most of these are available in the market and if not, a 5 min Google search will find an .apk on the net anyway.
So how about a bare bones install with the essentials and nothing else? Youtube, Phone, Messaging, Gmail, Contacts, MT Browser , Maps, Calculator... then anything else can be added at the users will.
If anyone else has something to say... or prove me wrong, then please elaborate.
If you delete the alarm clock task, you're likely to sleep into the morning as the alarm won't go off in the morning. Mail is probably needed for pop3 checks (I rely on my google account).
Anyway, I usualy remove the apps widgets from the ZIP which I don't need prior to flashing, resulting in a liter ROM and less processes which I don't need running in background.
I also used to add the apps I use (ASTRO...) directly into /system/app prior to flashing, putting them to the system partition and ... at this point I am not sure.... this leaves one with more space (internal memory) accessible for apps from market (if you do not use APP2SD). I stopped however doing so, as this makes ROM upgrading painful, as you do have to prepare each .zip before flash.
With regard to operating memory you preferably use either Taskkiller or have your systems autokill file optimized as many ROMS do (CursorSense). Refer to http://forum.xda-developers.com/showthread.php?t=622666
I'm not Linux-guy but I know that Android does this to put those programs in memory ASAP because those are usually the first few apps many people use once they boot up their phone -- meaning those apps, when opened, will quickly open and run faster.
Remember, Linux is made to handle all those opened apps and resources; "Unused RAM is useless RAM".
hol17 said:
I'm not Linux-guy but I know that Android does this to put those programs in memory ASAP because those are usually the first few apps many people use once they boot up their phone -- meaning those apps, when opened, will quickly open and run faster.
Remember, Linux is made to handle all those opened apps and resources; "Unused RAM is useless RAM".
Click to expand...
Click to collapse
Correct!!
People have to stop comparing Android (linux) with WinMo devices, they handle RAM completely different.
dione1200 said:
Correct!!
People have to stop comparing Android (linux) with WinMo devices, they handle RAM completely different.
Click to expand...
Click to collapse
Yes, true.... and well known. However Linux was developped for servers and not mobile phones.
Launching an application into free RAM is slower than pulling it from a suspended state. So much is true.
But first having to free up up RAM (by killing tasks) before launching the application into the freed up RAM is certainly slower than launching into free RAM. Probably that's why guys are tweaking around, as noted in the link of my post above. Also in my opinion the default settings are not optimal, that's why I use tweaked settings. Probably that depends on how you use your phone.
But I agree. Coming from Windows the whole LINUX concept is a f**** nightmare. There are thousands of different methods (Cache/Compcache/ Ext Cache)...
So it's good to have an expert around. Could you please enlight me, whether the system partition is of fixed size or size is been alocated during flashing. In other words, is the Userdata size fixed or depending on the system size? .... and is there a benefit of putting apps to the /system/app as they will go to system parition and I will have more internal storage available?
Thanks in advance.
feicher said:
So it's good to have an expert around. Could you please enlight me, whether the system partition is of fixed size or size is been alocated during flashing. In other words, is the Userdata size fixed or depending on the system size? .... and is there a benefit of putting apps to the /system/app as they will go to system parition and I will have more internal storage available?
Thanks in advance.
Click to expand...
Click to collapse
Your Android Device is divided Into partitions -> (Device memory)
1. Hboot (spl)
2. Radio
3. Data (Where u store ur data apps / passwords / other thing)
4. Cache (temp)
5. System (system dump)
6. Boot (to start the device)
so on
Now partition of memory card is important becoz
1. EXT2/3/4 More Amount of Data Section -> if device memory is less
2. Swap -> To fast up the system
*I m Not best Explaination giving person but i think this is understandable language in which i hav written
I think I side with the OP on this one, I would rather have a rom with less in it and then choose to install Amazon MP3 or whatever by myself. Generally speaking you could argue less apps = better performance, as there will be less happening in the background. That said, I have included Facebook in my rom.
However Linux was developped for servers and not mobile phones.
Click to expand...
Click to collapse
Not really true, Linux is just the kernel and can be ported to anything, it's been in embedded small devices for years and not just installed on servers.
ahmgsk said:
Your Android Device is divided Into partitions -> (Device memory)
1. Hboot (spl)
2. Radio
3. Data (Where u store ur data apps / passwords / other thing)
4. Cache (temp)
5. System (system dump)
6. Boot (to start the device)
so on
Now partition of memory card is important becoz
1. EXT2/3/4 More Amount of Data Section -> if device memory is less
2. Swap -> To fast up the system
*I m Not best Explaination giving person but i think this is understandable language in which i hav written
Click to expand...
Click to collapse
Thank you very much for the feedback! Most appreciated and helps me to improve my general understanding . I find it really hard to come by information, that is not absolutely basic or high level expert.
Thanks again.
Ive got a clock radio that wakes me up... if i have lagging issues with my phone what i do is use advanced task manager to stop all processes im not using (alarm clock, maps, messaging, email, etc) and everything runs fast again.
No use in reboot cause all the apps start again from boot.
ive tried removing zips from rom before flashing... when i goto upgrade the update stops cause of the missing files > incomplete manifest. is this cause you have to re-zip and sign it?
You can either do that and re-sign the zip file.
OR you could just close this thread and use adb to remove things that you dont want from the ROMs.
PS. root explorer also works wonders.
feicher said:
If you delete the alarm clock task, you're likely to sleep into the morning as the alarm won't go off in the morning. Mail is probably needed for pop3 checks (I rely on my google account).
Anyway, I usualy remove the apps widgets from the ZIP which I don't need prior to flashing, resulting in a liter ROM and less processes which I don't need running in background.
I also used to add the apps I use (ASTRO...) directly into /system/app prior to flashing, putting them to the system partition and ... at this point I am not sure.... this leaves one with more space (internal memory) accessible for apps from market (if you do not use APP2SD). I stopped however doing so, as this makes ROM upgrading painful, as you do have to prepare each .zip before flash.
With regard to operating memory you preferably use either Taskkiller or have your systems autokill file optimized as many ROMS do (CursorSense). Refer to http://forum.xda-developers.com/showthread.php?t=622666
Click to expand...
Click to collapse
when i try to remove an app from a ZIP it wont let me flash the ROM. even when i replace an app with a newer version renaming it to match the one im replacing, it still doesnt work. what do i have to edit in order to allow the update to go through?
You need to sign the zip file again. Google signing ROMs, its the first thing that pops up.
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?)
It's been going on for years - our forum and others continue to receive hundreds of requests every day from new and experienced Android users led into confusion over their device storage, with questions like these:
I have a 32 GB SD card, why can't I install all of the apps I want? It keeps telling me I'm out of space!
I have a 4 GB phone, I don't have that many apps, but it says I'm out of space again. WHY?
I have an 8 GB tablet and I can't make heads or tails out of what's up! I've looked at my settings and it says I have all sorts of storage! What the heck is up here?
And the follow-on questions - Is it broken? Did I get ripped off?
Sound familiar?
I bet it does, it's probably hit all of us at some point - and is still hitting people every day.
The truth is that apps telling you about your storage fall into one of two categories:
Apps trying to be too friendly in helping you, designed really to tell you about your media storage
Apps that bury the real information inside screens and popups that try to tell you everything about your phone
The problem is simple:
The first type of app is not telling you the right story
By the time you understand the second type, you already know the answers
The deck is stacked against you, it's a complicated mess
Having folks type and interpret the Linux df command output from an adb shell or an on-device terminal emulator is an option, but is not always effective:
Scary for a lot of people
Complicated
Difficult to read
Information overload
So, we sat down and designed a simple, straight-forward app that shows you how much storage space you have on your device for apps that you want to install or update.
The results are shockingly simple and we call it Storage Truth.
EASY to understand!
Instructions about what is going on with your storage spelled out right at the top!
Focused to just give the facts that you care about for your app storage and how big your system is!
Evaluated by Google to support over 8000 possible devices, and not work on ZERO of them!
Requires no special permissions - at all!
Is free, contains no ads, no in-app purchases, trackers, lookers, peepers, pop-ups, notifications or anything else you don't want! Just the truth - the Storage Truth!
Output is also copied to the clipboard for sharing with others.
Get it in the Play Store - https://play.google.com/store/apps/details?id=sa.storagetruth
or download it here: View attachment StorageTruth-v1.0.apk
- - -
Hi all!
I was thinking about some way to reduce list of apps installed on my device. Ergo: to get more /data & /system (and other partitions) free space to my advantage.
Testing platform:
Phone: Samsung Galaxy Trend Plus/GT-S7580/kylepro: http://www.phonearena.com/phones/Samsung-Galaxy-Trend-Plus_id8239
ROM: AOSP 7.1.2 (15.06.2017 build): https://forum.xda-developers.com/s7582/development/rom-aosp-7-0-galaxy-s-duos-2-trend-plus-t3472072 - main thread for this ROM.
AOSP 7.1.2 download link: build.sandpox.org
Launcher: Nova Launcher Prime 5.3 beta 2:
https://play.google.com/store/apps/details?id=com.teslacoilsw.launcher&hl=pl - Nova Launcher
https://play.google.com/store/apps/details?id=com.teslacoilsw.launcher.prime&hl=pl Prime Unlocker
Icon pack: Noctum Iconpack 1.9: https://play.google.com/store/apps/details?id=com.mlv.noctum&hl=pl
I started by deleting unwanted apps, but that wasn't enough. I was thinking about replacing some "core" apps from /system partition (e.g. Dialer, Gallery, etc.).
But there was a problem - how do I replace them ?
So I did some searching & found four solutions (I know there are dozens of this kind of apps. but I focused ONLY on this apps):
FOR REPLACING SYSTEM APPS WITH ONE APP:
1) "fooView":
XDA: https://forum.xda-developers.com/android/apps-games/app-fooview-alpha-im-t3326901
Play Store: https://play.google.com/store/apps/details?id=com.fooview.android.fooview&hl=pl
But that wasn't it. I didn't liked it. Some "unnecessary" features (at least for me, that's why it's in quote) & high (In my opinion!) RAM usage by the app marked this app as unusable for me.
But I need to thank the Dev, for letting me dive into it more & search for more suitable solution.
2) "Multitasking":
XDA: Couldn't find, does not exist on XDA ? If it is on XDA, then PM me, I will update the thread with those links. Thank You!
Play Store: https://play.google.com/store/apps/details?id=com.oryon.multitasking
Idea behind this app is very good, but it was crashing & force-closing often. Don't know why, I had always about 300MB of free RAM & CPU usage also wasn't that high.
Also disability to add my own apps & URL links and convert them into floating apps was a dead end for this app (once again - at least in my opinion!).
3) "Floating Apps":
XDA: Couldn't find, does not exist on XDA ? If it is on XDA, then PM me, I will update the thread with those links. Thank You!
Play Store: https://play.google.com/store/apps/details?id=com.lwi.android.flappsfull
Tried it with some disbelief that it will work, but... IT WORKS! THIS IS IT! All is working fine, many themes to choose from.
Great multitasking app! More than 35+ apps included! Dialer, Image viewer, Calculator & more!
Also it has ablility to convert apps & URL links into floating apps!
Works flawlessly, it will stay with me for sure!
But there are two small negatives (in my opinion!):
a) DON'T USE "Quick Launch Icon" on a devices with small RAM amount (like mine) - it increases RAM usage by 300% of the main process of the app.
With QLI: 68MB of RAM used
Without QLI: 16MB of RAM used
b)DON'T DELETE "Contacts" app (and "Contacts Provider" from obvious reasons) from Your phone before syncing contacts from cloud/importing them from .vcf file. "Contacts" app in "Floatnig Apps" can't sync/import contacts - it can only add new ones.
c)DON'T DELETE "Dialer" app (and other apps related to this app) from Your phone, because after deleting it, if You will try to make a call, the "InCallUI" won't show up. Phone will start ringing, but that UI will not show up, so You won't be able to accept/decline a call.
ONE APP FOR TWEAKING ROM*:
(One app to rule them all! XD)
1) 3C Toolbox Pro:
XDA: https://forum.xda-developers.com/android/apps-games/app-2-3-3c-toolbox-pro-t2942186
Play Store: https://play.google.com/store/apps/details?id=ccc71.at&hl=pl
It's a REALLY GREAT TOOL for tweaking ROMs to Your preferences. It has over 80+ tools in ONE app! (just read Play Store description)
It has CPU, RAM, ROM managers, build.prop editor, terminal, battery calibrator & MANY MORE in ONE app!
It's worth it's price.
#IHighlyRecommendThisGreatApp
SO, IT'S TIME TO COMPARE IT:
Before:
About 60-70 apps installed in the device.
Almost 2GB's of ROM memory used
Above 400 MB of RAM used
After:
ONLY 26 apps installed in the device.
Under 1.9GB's of ROM memory used
Under 320 MB of RAM used
Press "Thanks" button, if I helped You somehow. Best regards for You!
But overall, I need to thanks all this people for their work, so...
Credits are going to**:
@fvalpha for his "fooView" app.
OryonCorp for their "Multitasking" app.
LWi s.r.o for their "Floating Apps" app. @3c for his "3C Toolbox Pro" app!
@sandpox for creating a "starting point" for ROM development onto my device & for developing some first ROMs onto this device.
@no_name for creating this great ROM.
@DodoGTA for help with many things related to my device.
@sostk22 for help with many things related to my device. @DNikola for being a nice person. XD
Whole "GT-S758x team" group for so much help & a nice atmosphere in the group.
Whole XDA Community - thanks for existing. XD I have learned SOOOO MUCH with You**, here on xda-developers.com . Thanks to all of you!
*If I have forgot about someone, PM me.
**But I have still SOOO MUCH to learn! Will stay on this forum for a LOOONG time, for sure!
You can't get "full" 4GB from this device, the 4GB are the actual physical EMMC chip capacity, meanwhile it has been splitted to a lot of partition and /data is only max ~2GB
no matter how much you've deleted in /system, your usable capacity of /data will stay the same, unless you do a repartition which is extremely risky and cannot recoverable if it once screwed
The available RAM will depend on how much background apps are running though... but you don't expect to get more than 500MB usable since 200MB will be use to run the OS itself
The actual RAM chip is 768MB but it has been shared with GPU so only ~712MB is available for OS and your apps
so don't fully believe in whatever the OEM claims about the memory capacity, it will be a lot of different because of the unit and the system itself has consumed, my current device is claimed 32GB but only 28GB available for /data
sandpox said:
You can't get "full" 4GB from this device, the 4GB are the actual physical EMMC chip capacity, meanwhile it has been splitted to a lot of partition and /data is only max ~2GB
no matter how much you've deleted in /system, your usable capacity of /data will stay the same, unless you do a repartition which is extremely risky and cannot recoverable if it once screwed
The available RAM will depend on how much background apps are running though... but you don't expect to get more than 500MB usable since 200MB will be use to run the OS itself
The actual RAM chip is 768MB but it has been shared with GPU so only ~712MB is available for OS and your apps
so don't fully believe in whatever the OEM claims about the memory capacity, it will be a lot of different because of the unit and the system itself has consumed, my current device is claimed 32GB but only 28GB available for /data
Click to expand...
Click to collapse
Thanks for answer. Will do some changes in thread. Thanks for showing me my mistakes.
First i want to thanks to you for mention me..and tnx for your help with my problems and qustions.And now thanks for this thread.
Now i want to know can i try this on lineage14.1 ?
Sorry for bad english
DNikola said:
First i want to thanks to you for mention me..and tnx for your help with my problems and qustions.And now thanks for this thread.
Now i want to know can i try this on lineage14.1 ?
Sorry for bad english
Click to expand...
Click to collapse
You can try it, for sure! It will work.
Thanks for the mentions of fooView.
In my opinions, fooView is a floating icon app using machine learning mechanism to improve productivity.
All features in it are connected in the end. And it can be customized, so you need not use each feature, which would not start until you start it manually.
For the RAM, as a 6M apk, fooView takes a very little RAM as a floating icon, so it can run on almost every Android 4.1+ device. A special case is when fooView window is opened as any other browser, the system webview will cost much RAM to utilize your device performance(system costs more when your device is better), and release them when you close the window, it's used by the system and should not be counted into normal RAM usage (you might find the realtime usage in the developer mode in the system settings).
fvalpha said:
Thanks for the mentions of fooView.
In my opinions, fooView is a floating icon app using machine learning mechanism to improve productivity.
All features in it are connected in the end. And it can be customized, so you need not use each feature, which would not start until you start it manually.
For the RAM, as a 6M apk, fooView takes a very little RAM as a floating icon, so it can run on almost every Android 4.1+ device. A special case is when fooView window is opened as any other browser, the system webview will cost much RAM to utilize your device performance(system costs more when your device is better), and release them when you close the window, it's used by the system and should not be counted into normal RAM usage (you might find the realtime usage in the developer mode in the system settings).
Click to expand...
Click to collapse
Thanks for answer. I know about that Real Time RAM Usage (You're talking about "Running Services"). In my post, all RAM info is based on that "Running services" tab in Developer Options.
And (in my opinion!) it is too high. But when I will get a better device with more RAM, I will start using it for sure. About that "unnecessary" features, I was talking about functions, that this app duplicates, I'm not saying they are unnecessary per se. I think You get the point.
Idea behind this app is very good, so...
I wish You luck & success with this (and others!) project. Best regards.
https://drive.google.com/open?id=0B4q2ZkMZt4BjdjVFVnN3aW9xb28
I got this from indo friend
Can someone here check it and report about what it work or not ?
On our device ?
Guide : Add this file to system/bin