Database Info

A2SD users rating apps 1* for force closes...

Example:
http://www.cyrket.com/package/com.google.android.stardroid
As a developer, I am sick of the stream of spammorhea from users who are downrating apps that are crashing not due to poorly written code but because the user installed A2SD. You install and use A2SD at your own peril. If you are using A2SD and you experience force closes when non-A2SD users are not, I guarantee you 99% of the time it is because you are using A2SD.
DO NOT REPORT CRASHES OR FORCE CLOSES TO APP DEVELOPERS IF YOU ARE USING A2SD.
Developers have enough on their plate without having to troubleshoot the problems of users who are using extremely non-compliant Android environments. Uninstall A2SD and try again, go read a book, or shoot yourself in the head, but ffs do not report your crashes.

or like the people that rate 1 star on an app that says for cupcake only and they don't have cupcake. and complain it don't work.

one thing i just noticed since you posted the sky map app, i'm assuming your saying that program won't run with apps2sd. i have apps2sd and when i click on the app in my app list it pops up saying program not installed (guessing since running off sd). but i put it on my desktop and ran it it worked. any explanation.

whoops
this thread just forced closed, no apps to sd...???

supremeteam256 said:
any explanation.
Click to expand...
Click to collapse
That's part of the problem. Some folks are using symlink version, others are using unionfs version. Some have just /data/apps moved, some have dalvik-cache moved, some people move entire /data. Worse than the fact that A2SD mod is inconsistent with the standard android environment, each user's A2SD environment itself is also inconsistent with other A2SD users.
This kind of unorganized and mostly untested hack is a huge freaking headache for developers. Hackers generally release hacks as-is. That means that they usually don't need to have the hack thoroughly tested before release (part of the reason being they let the community do the testing). On the other hand, app developers, for the most part, have to provide support for their products. This support makes presuppositions about the user's Android environment, such as the security of the /system folder, the location of dalvik-cache, etc.
When taking a device outside of the boundaries of the official Android environment (that is to say by rooting and installing unsanctioned hacks), a user needs to understand that he/she may be causing program instability. Inexperienced users who install A2SD and other experimental hacks and then improperly attribute crashes to downloaded apps are hurting both the hacking community as well as the app community.

I concur. 90% of recent posts are newbies with no linux experience complaining about A2SD not working. It's no wonder JF stopped being involved on the forum.

I'm running JF v1.5 with my apps and dalvik-cache moved to sd (not data though) and just downloaded that star app. Works perfectly fine. I didn't use an app to move my a2sd though, I did it through adb.

While I understand the poster's frustration this topic could/should simply be narrowed down to a rant about people rating apps based on user error or poor judgment.
The large volume of rooted/apps to sd users in the android community is directly proportional to the poorly thought out memory amounts of the G1 phone. So in this case there will continue to be a lot more average joes to contend with.
So, before the Newbs are burned at the stake remember this is a symptom of a problem created by the very progenitors of the Android platform, they are responsible for the hordes of ill equipped G1 toting Linux newbs.

wyseman76 said:
The large volume of rooted/apps to sd users in the android community is directly proportional to the poorly thought out memory amounts of the G1 phone. So in this case there will continue to be a lot more average joes to contend with.
Click to expand...
Click to collapse
Seems like you're confusing proportionality with causality. However, sure I completely agree that a lot of the hacks on the xda-dev forums are a result of hackers wanting to fill in the gaps of stock Android. Necessity is the mother of invention, as it were. To that extent, I am not against the unsanctioned development of hacks for Android. In fact, I wholeheartedly support it. Android's openness (despite root-jails for carrier branded phones) is one of its unique strengths.
What I am railing against is newbies who jump right into a hack without reading the instructions and hackers who release hacks without enough testing or carefully written and concise documentation. That's somewhat like giving a loaded gun to a toddler. (Sorry for the melodramatic and cliche simile.)

i agree totally- i try and mark those kind of messages as spam on the market,.... i wonder how people actually rooted their phones if they are unwilling to read a bit more info.....

I've run both the symlink version of A2SD and the unionfs version. I set up both from command line, not the apps. I have no issues at all with Google Sky Map or indeed any other programs at the moment.
Personally, I blame the A2SD apps for the problems other users are having.

Hi,
I use 5.02h R4 app2sd with the above method and no problems with force closes with 65 apps installed.
It helps to use a class 6 card also.
Just used basic command lines, no scripts.
DOHCtor said:
I'm running JF v1.5 with my apps and dalvik-cache moved to sd (not data though) and just downloaded that star app. Works perfectly fine. I didn't use an app to move my a2sd though, I did it through adb.
Click to expand...
Click to collapse

DOHCtor said:
I'm running JF v1.5 with my apps and dalvik-cache moved to sd (not data though) and just downloaded that star app. Works perfectly fine. I didn't use an app to move my a2sd though, I did it through adb.
Click to expand...
Click to collapse
I used the script and have everything moved to my sdcard. The result after installation of the app was an error message stating Sky Map wasn't installed. I then decided to reboot and the app worked fine.

Just an addition to my post, I moved everything to SD - dalvik-cache, /data/data etc and no problems at all.

The browser force-closed on me, where can I rate it 1*?

I have a feeling that a lot of the crashes/force closes are due to the speed of the SD card. Let's face it the OS expects a certain read speed and the SD cards can't quite keep up (class 6 works most of the time). When the OS issues a command and it doesn't execute in a given amount of time it assumes the app has crashed and posts a message asking if you want to force close it. Of course the correct answer is to hit wait.
It would be nice if the OS hackers could find out where this time limit is set and tweak it to be a bit more forgiving. This would probably solve a whole lot of problems people are seeing.

JaboJG said:
I've run both the symlink version of A2SD and the unionfs version. I set up both from command line, not the apps. I have no issues at all with Google Sky Map or indeed any other programs at the moment.
Personally, I blame the A2SD apps for the problems other users are having.
Click to expand...
Click to collapse
I am using JS 1.5, and I created the Symbolic Links using the Terminal Emulator. I moved Apps and Apps-Private. And Removed the respective folders from System. 95% of my apps work as is, I think I had to remove a couple for cupcake reasons, no biggie.
That SKY Program didn't work for me. I am going to try reinstalling it, and see what happeneds. Otherwise someone here said they also moved Dalvik-Cache, I may try that. I was assuming this was always a Cupcake Compatibility problem.
Edit: Using Class 6 MicroSD Formatted 7.5Gb FAT32 / 450MB Ext2

Just throwing in a my 2 cents. I have no problems with A2SD. Only issue that i've had is with open home, seemed like it slowed everything down. Never force closed just seemed slower than when it was ran normally.

Rekna said:
I have a feeling that a lot of the crashes/force closes are due to the speed of the SD card. Let's face it the OS expects a certain read speed and the SD cards can't quite keep up (class 6 works most of the time). When the OS issues a command and it doesn't execute in a given amount of time it assumes the app has crashed and posts a message asking if you want to force close it. Of course the correct answer is to hit wait.
It would be nice if the OS hackers could find out where this time limit is set and tweak it to be a bit more forgiving. This would probably solve a whole lot of problems people are seeing.
Click to expand...
Click to collapse
I don't think this is always the issue though. Specifically with this App on my phone. Wait will do nothing. As soon as you launch the App, it come up with Force Close Immediately. Almost like it expected to find data / something, somewhere and didn't so it had to close.
I dunno if this is a possibility with Symbolic Links, but maybe it saw the Symbolic Link and instead of following it, saw it wasn't a directory and crashed? While it was looking, or trying to store cache data perhaps?

I must say, trying to go to appstosd was one of the biggest headaches Ive ever experienced hugely because of the problems listed here. I have been through just about problem you can experience with appstosd and because I wanted to understand what was going on I finally figured it all out and have been able to run appstosd flawlessly for days now. All you need is to accept trial and error and BACK EVERYTHING UP!!!

Why cannot we dual boot?

I was thinking that dual booting on a single device would be a really great thing. A huge step.
Why we cannot do it?
Cannot we "emulate" partitions of the internal memory on the sdcard and then create a modified spl to boot from sdcard?
I was thinking that it is possible to make the sdcard working like internal memory..
Is it so difficult?

blackgin said:
I was thinking that dual booting on a single device would be a really great thing. A huge step.
Why we cannot do it?
Cannot we "emulate" partitions of the internal memory on the sdcard and then create a modified spl to boot from sdcard?
I was thinking that it is possible to make the sdcard working like internal memory..
Is it so difficult?
Click to expand...
Click to collapse
I think this would be a good idea too. have a stable boot partition, then on the second boot have our "testing" partition.
Is this even possible?

Whether or not this is possible, I don't know.
But kinda related, I would like to see a bootloader that made an "image" of the entire phone to sdcard AND would also restore the entire "image" of the phone.
Why?
It would give us an easy way to test out different roms!
You could have your stable build for regular day-to-day use, you could also "image" any other rom you install, then you could switch back and forth without the need for a computer to restore using Fastboot. Using this method, you could "image" any number of builds you wouldn't to try.
There may be a way this could be done right now, I don't know. I haven't found out how. If it's already an option, someone please point me in the right direction!

It would be very difficult cause you would have to find another OS that isn't linux based. Even with a bootloader all the files will be knocked off from the previous flash because everything in these builds are pretty much in the root folder. The OS runs on these references and if you change them the OS will not run. You would have to rework the whole OS to get this to work

Someone delete me

argh xda is so slow

It would be very difficult cause you would have to find another OS that isn't linux based. Even with a bootloader all the files will be knocked off from the previous flash because everything in these builds are pretty much in the root folder. The OS runs on these references and if you change them the OS will not run. You would have to rework the whole OS to get this to work

Booting off the sdcard could be possible but would be pointless to do.
Everytime you mount the sdcard to the computer it would crash the phone. Also, There's not really enough internal space to dual boot. 1 decent ROM barely fits on as it is.

blueheeler said:
Whether or not this is possible, I don't know.
But kinda related, I would like to see a bootloader that made an "image" of the entire phone to sdcard AND would also restore the entire "image" of the phone.
Why?
It would give us an easy way to test out different roms!
You could have your stable build for regular day-to-day use, you could also "image" any other rom you install, then you could switch back and forth without the need for a computer to restore using Fastboot. Using this method, you could "image" any number of builds you wouldn't to try.
There may be a way this could be done right now, I don't know. I haven't found out how. If it's already an option, someone please point me in the right direction!
Click to expand...
Click to collapse
Cyanogen mentioned he was looking into this to try implement it into his recovery image. I don't think anyone's been able to restore a complete nandroid backup outside of fastboot...yet. However people are working on it. I think it's doable.
Meltus said:
Booting off the sdcard could be possible but would be pointless to do.
Everytime you mount the sdcard to the computer it would crash the phone. Also, There's not really enough internal space to dual boot. 1 decent ROM barely fits on as it is.
Click to expand...
Click to collapse
Maybe, maybe not. A second or third EXT partition on the sd card could possibly be used for a dual/tri boot enviornment. Only the FAT32 portion gets mounted when you mount through your phone. And there would be virtually no difference when mounting through ADB. Now would be a good time for those interested in persuing this notion to have a look at the data2sd thread. Sounds very possible to me.

overground said:
Maybe, maybe not. A second or third EXT partition on the sd card could possibly be used for a dual/tri boot enviornment. Only the FAT32 portion gets mounted when you mount through your phone. And there would be virtually no difference when mounting through ADB. Now would be a good time for those interested in persuing this notion to have a look at the data2sd thread. Sounds very possible to me.
Click to expand...
Click to collapse
no, i'm pretty sure all partitions get mounted, they just don't show up on windows.
on linux they all appear for me when i mount the phone.
also, sorry about the triple post, dunno wtf happened there.

Debain As Primarly OS
What Ive Been wishing for is someone to make the Dream Boot straight to Debian, No android running in the background.
Then we could boot into a debian with g1 drivers (if open source) and have gpu accl. x11.
Then maybe dual-booting android.
Im willing to try to get a debian img to boot on my g1 if someone wants to tell me where I would start to even try to attempt it.

lolz
Booting straight to Debian would be cool, except there is really no use for it on our G1's. We are best off running after loading Android, although I'm sure one day we could just boot Debian. What would the point of Debian be on our G1's? I'm running Deb5 on my Dell Mini that has a 9" inch screen and can barely see text.... how in the world would this become useful on a 3" screen???

just my £0.02
there is an old saying in my country. "if you don't believe it can work, then it won't for you". that holds so true for development. yes you will make mistakes on the way. heck i'm on my fourth G1 so far (and i suspect there will be more to come!) I love this phone, and i love the fact that we as a community can build such amazing things as the hero rom for the device.
what would we have done if the first person had said the wheel was impossible? or if the first person had said that fire was impossible. or (shock horror) electricity? or television? or telephone? or GPS? or the internet?
all of those were impossible until someone worked out how to do it.
dual boot would be pheasably posible, as the device is primeraly a computer first, and then a phone second. it boots a linux kernel from the bootloader (if i am correct in my understanding) so all we would need to do is create a bootloader with a choice in it, and then direct the phone to boot a second partition from the SD card.
the phone does mount all partitions - but only if the OS understands all partitions (test it for yourself - if you have windows and apps2sd mount the partitions and then run an app from the card it still works. but it does not under linux).
to answer the what would be the point questions, what would be the point in not doing it? surely development for a device like this is all about trying stuff, and then if it doesn't work not doing the same thing again.
i believe that a second OS would boot quite comfortably on a decent SD card. not that i have this working or anything. to make the screen readable, you just use a lower resolution (320x480). i would probably not want a full-blown GUI linux anyway, what i would want from a dual-boot OS would be a working command-line debian with FULL hardware access - allowing me to really use the phone as a fully-functioning remote terminal for my server.
i recon, though, that one thing that would be absolutely amazing is being able to have a fully-portable totally reliable XDA-Developers OS on my phone.
so, why do we not just try as much as we can to get this working? how do we start?

milestone.it said:
just my £0.02
.....
so, why do we not just try as much as we can to get this working? how do we start?
Click to expand...
Click to collapse
Just hack the spl and flash it, but be cautionous as hell

Okay, I dont claim to know alot but I'll share my thoughts anyway
When you mount the SD all partitions get mounted, if you go into disk management in windows you can see the 'Unknown' partition if you have an ext2 partition.
Secondly, we don't really 'boot' debian, it just mounts an image file on your SD card that contains the debian binaries. As I understand it there is no reason these binaries couldn't be included in android (like busybox).
Thirdly, do we really want debian? What we need is a very light OS, android is the perfect base, take away all the gloss and its linux underneath. I love the idea of having repositories and being able to apt-get and even develop on the device.
Lastly, we're forgettign why android is such a good platform, the reason android is useful is because of the Dalvik VM, it's what allows us to make portable apps that will work on any android phone. I seriously doubt everyday users will be interested enough to learn to compile source on their phone. I've worked programming games for mobiles in J2ME and it was horrible, there was barely any portability between manufacturers, i believe android will be alot better adn from what i've seen (with people porting from other droid devices) this seems to hold true. It will be interesting to see if Android gets bloated with manufacturer specific API's like J2ME.
Also I'll just throw this out there... I'm not a fan of being tied to google, yes google helped along the way, but its not 'google android', its android. Wasn't it strange hoe Gmail worked fine, but the email app didnt? (K9 is perfect though!)

hi guys, i'm not at all a developer of any kind, i suck even at web design, but here's my thoughts expanding on the whole "what if the wheel didn't work" scenario
inventions are created by the need to do something, we need to get from A to B faster, lets make a car. we want to entertain our families in the evening, Hey look, TV. i need to tel my wife to get some milk while she's at the shop, Voila, Mobile Phone.
Basicaly the point i'm trying to make is, if somebody finds a NEED for dual boot on android, then so be it, it shall be done, maybe not today, maybe not tomorrow, but if something is needed, then something shall come from it. we develop technology when we need to do something faster, easier, or just plain do it.
if somebody decides they NEED dual boot, i'm pretty sure they will figure out how to do it, either that or ask haykuro for some tips and alot of help, but i think he's still too busy with regular life at the minute, i'm not so sure, all i know is he's definately a legend, and maybe will want a piece of dual-boot pie

So who is the great man who want to try to do this? ;D
I offer my help, if it could be useful..

re: dual booting
would it be blasphemous to want to try out winmo 6.5 or 7 on these?

personally, i'd love to see WM on here. mainly, just so we know it's possible.
People are always slating Windows but, personally, i don't see whats wrong with it (Linux is my primary OS and always will be ). It would be nice to have say WM for work and Android for play

any news on this? I would really like to run a hero rom one day and then cupcake the next while not losing my settings...

Project: apps-on-sd to AOSP -- developers needed.

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

Noob Dictionary

So I am stealing this from another forum, hopefully it will cut down on some of the repeated threads. Copy and pasted to reduce the strain on my brain and typing.
Stolen from the Sprint Hero board on AndroidForums.com - Props to PDragon for typing it all. I have slightly modififed.
ROM - Read Only Memory
While the term has changed a bit from it's original meaning, it's essentially computer memory that does not require power to store it's data (non-volitile). In the sense of a smartphone like the Hero, it's the Internal Memory where the OS is stored. From what I've gathered, the Internal Memory is just Flash Memory (a special type of ROM) partitioned into two parts, one for the OS and the rest for apps to use. So, the OS partition essentially is true ROM, unless you root the phone. The software that groups like xda-developers make available are called ROMs because they're a ROM Image.
For the Hero this size is 512MB.
SDcard is a larger capacity external Flash Memory card.
Recovery Rom - I would assume enough said, but. This is the recovery partition of the phone for when things go bad, typically how you will load your ROM packages, some times refered to as "Update.zip" files.
Vanilla Rom
All the fancy bells and whistles have been pulled out so that its as minimalist as possible, users can then build on this for their own custom setup.
RAM - Random Access Memory
This is where current processes that are running are stored and keep the data they need immediately available to them. This is the memory you see when you run any of the Task Managers showing you currently running apps and the available memory. It's a completely different part of the phone from the Internal Memory discussed above. Data stored in RAM requires constant power and does not survive a power cycle of the phone (volitile).
For the Hero this is 288MB.
Root
This is the term being thrown around for modifying a smartphone to put custom software on it that normally wouldn't be allowed through means included with the phone (Android Market or an .apk file for a non-Market app). "Root" is the common term chosen because, in a Unix environment, the "root" user has complete and total control of the entire operating system of the computer. So, "rooting" the phone means taking complete control over its operating system. This is usually done by means of finding a flaw somewhere in the phone's firmware to allow access to the restricted Internal Memory where the OS resides. You then install a custom ROM (see above) to let you use your phone from then on.
Android is a bit more unique than any of the previous smartphones in that you don't really need "approval" from a higher power (ex, the Apple store) to install an app that hasn't made it onto the Market. Just uncheck the box Settings -> Application settings -> Unknown sources and you're free to install any .apk file you wish. So Android phones are more like a regular computer in that you're free to install whatever software you want from whichever source you want. Just be careful of where you get apps from outside of official Market sources. Also like a regular computer, you could open yourself up to having your personal data stolen.
Rooting still gives some advantages for power users, but for normal or even intermediate users, you probably don't need to root the phone to enjoy it as much as you'd have needed to for previous smartphones.
For further discussion, please see our Developer Forums.
Tethering
This is the term used for using your phone as an Internet access point to allow an attached computer to access the Internet. It turns your phone into a mobile modem. Please don't discuss Tethering here. See the thread Does Tethering work? to discuss this further.
*Let me know if we should add other terms. Maybe a MOD can stickie this.*

but where are the guides

jtadeo said:
but where are the guides
Click to expand...
Click to collapse
I think all of the guides have been Stickied on the first page of the board. Do you need one in particular??

At the bottom of the main forum is a dictionary for anyone to use. I don't see the point in this unless it is made for lazy people that just want what they want now and can't take time to research.

tdavis42 said:
At the bottom of the main forum is a dictionary for anyone to use. I don't see the point in this unless it is made for lazy people that just want what they want now and can't take time to research.
Click to expand...
Click to collapse
Do you think we would have as many of the new user questions repeated over and over if they did take time and do the research? Think not... You must have some real faith in humanity if you think people won't take the easy way out if it is offered. Hence my copy and paste from another forum.

What was a SDcard? and I'm not understanding the concept or RAM....
hahaha, just joking..
Nice work, I'm sure this will come in handy for some folks!

for all other definitions check out : http://wiki.xda-developers.com/index.php?pagename=Glossary

N0J said:
What was a SDcard? and I'm not understanding the concept or RAM....
hahaha, just joking..
Nice work, I'm sure this will come in handy for some folks!
Click to expand...
Click to collapse
I am not making fun of anyone, I have been there my self. But I have seen the above questions on other forums! lol.
I must say XDA members tend to be a little ahead of the learning curve.

Search Button!
jtadeo said:
but where are the guides
Click to expand...
Click to collapse
Search button is your FRIEND!!!

Kcarpenter said:
I am not making fun of anyone, I have been there my self. But I have seen the above questions on other forums! lol.
I must say XDA members tend to be a little ahead of the learning curve.
Click to expand...
Click to collapse
lol, yeah
xda is good
jjjjayd13 said:
Search button is your FRIEND!!!
Click to expand...
Click to collapse
but the search button is terrible, lol
I've even seen a disclaimer on a mod's signature saying that it sucks and to use google, haha!

Anybody using Dropsync with 5.0.x?

The app developer hasn't updated it for Lollipop's new folder hierarchy permission, and he seems to be pointing everyone who asks about it to his Kitkat workaround (https://metactrl.com/docs/sdcard-on-kitkat/). I tried to create the necessary directory via ES File Explorer, but it couldn't create it. Consequently, Dropsync has become completely useless for me. Does anybody use it and have advice? I might be willing to root it if it solves the problem entirely... I hadn't had a reason to root prior. Lollipop penetration is so low that I can't find information on it anywhere else, hence why I'm hoping someone with a Shield has figured it out.

Unfortunately the only apps I've seen accessing the file system properly are the ones that have the special lollipop hack that it looks like was begrudgingly added at the last second.
That much being said, it is ENTIRELY possible that if you are not able to write to your SD card, it is because the SD card is not properly formatted. I recently posted an article somewhere in this forum about how I reformatted my SD card and got apps to write to it and everything was peachy keen.
http://forum.xda-developers.com/showthread.php?t=2973307
Disclaimer: I really hope this works for you but given my Thanks it's only been called functional by one other person besides me.

I actually did try formatting as NTFS (after seeing your post) and it was unsuccessful. However, I did quick format and I see now that your post says to format it twice. Perhaps I'll try it again this evening.
Thanks for your input, either way!

Any reason why not to root? DS works fine for me on 2.1 and starkissed kernel

Mathman85 said:
I actually did try formatting as NTFS (after seeing your post) and it was unsuccessful. However, I did quick format and I see now that your post says to format it twice. Perhaps I'll try it again this evening.
Thanks for your input, either way!
Click to expand...
Click to collapse
I'm sorry to hear that. I probably formatted my SD card a couple times too.
berryman13 said:
Any reason why not to root? DS works fine for me on 2.1 and starkissed kernel
Click to expand...
Click to collapse
Because warranty. Because good old days of not needing root.

Regarding root, I simply haven't had a need to with the Shield. With my phones and older tablets, there is functionality that I could only gain through root. But with the Shield, it's not like I'm removing carrier bloat, tethering behind the carrier's back, etc. I'm not necessarily worried about the warranty aspect... I do have microscopic hairline fractures on the corners, but I'm not petty enough to submit for a warranty exchange for cosmetic blemishes that don't affect performance, and I don't foresee other warranty-worthy issues.
Would root allow me to completely resolve the issue, though? As I mentioned, the developer's write-up specifically covers fixing the issue on KitKat, not Lollipop.

berryman13 said:
Any reason why not to root? DS works fine for me on 2.1 and starkissed kernel
Click to expand...
Click to collapse
OFF TOPIC but, what is the starkissed kernel? I searched the shield tablet forum for that keyword and this was the only mention it found....

PSA: If you encounter a problem where an app asks for write permissions for the sd card, but selecting it in the documents menu that pops up causes it to crash, format the drive as NTFS and assign a volume label. I had formatted as NTFS but not assigned a volume label and had this issue... once I assigned a label, it was remedied.
And the dropsync developer is updating the app to support these permissions very soon.