yashsingh1/xdaforums huggingface dataset:
[Touch Pro2 CDMA] seamus24:
It would be far to easy to say that Microsoft sucks.... but come-on... they've known about issues with finding people on CDMA for months now and there is no sign of a fix. Google can lock on to a CDMA signal and give an approximate location - Why can't Bing?

The market for smartphones was Microsoft's to lose and they have done a marvelous job of doing just that. How can companys with much less resources put forward the amazing operating systems like Apple, Palm and Google and even Nokia, while MS just sits on its hands and loses its market. My next phone will NOT be a Windows phone.
[Touch Pro2 CDMA] WatermelonSlim:
I just hope they get it together. There is no reason why Google Maps should be getting tower location info and Bing can't.
[Touch Pro2 CDMA] slick69:
The Imagio that I played with had the Location Weather just like my cooked TP, so I'm guessing you just need to wait for a new ROM. Also, you can hack in a ROM but you can't hack in a 3.5mm jack ;)
[Touch Pro2 CDMA] dkdontforget:
i think hes talking about the cell tower triangulation that GSM can do which soon as u get a data connection its finds ur position instantly withing something like 2300meters. im not sure if CDMA can do that. but it is useful somewhat if u dont have a GPS signal it gives u a general location or can search for things nearby
[Touch Pro2 CDMA] Telek:
It's called Assisted GPS and both GPRS and CDMA can do it. Telus' CDMA is within 1200ft or 800ft from experience depending on the number of towers it can see.
[Touch Pro2 CDMA] WatermelonSlim:
It may technically be possible for CDMA to do it, but the Bing app can't do it on CDMA devices. This is a known limitation that a Microsoft rep posted about over on the Bing forums...
[G1 Android Development] lbcoder:
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.
[G1 Android Development] lbcoder:
Really? Nobody AT ALL is interested?

This is the *ONE* major feature missing from AOSP!
[G1 Android Development] Zarboz:
Id PM twistedumbrella and cyanogen and shafty

JAC would prolly be interested but hes been busy with personal stuff i guess?
[G1 Android Development] sykokenndogg:
Just keep bumping this thread to keep it at the top. this needs to be done, and is long overdue on android...
[G1 Android Development] axlastro:
It's a must

I'm sorry that I'm not a developer. Good speed!
[G1 Android Development] jubeh:
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.
[G1 Android Development] Introspektive:
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 :)
[G1 Android Development] sykokenndogg:
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?
[G1 Android Development] lbcoder:
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.
[G1 Android Development] kolomari:
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.
[G1 Android Development] sykokenndogg:
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
[G1 Android Development] prince.siraj:
i agree. this should DEFINITELY stay at the top :D 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
[G1 Android Development] Joe333x:
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.
[G1 Android Development] Janis:
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.
[G1 Android Development] jubeh:
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.
[G1 Android Development] axlastro:
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 -.
[G1 Android Development] fosormic:
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.
[G1 Android Development] lbcoder:
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.
[G1 Android Development] random_username_:
well the extremely hacky piece of junk took a lot of hard work from the developers here......show some respect
[G1 Android Development] Chahk:
I'm sure he is. "Extremely hacky" does not necessarily mean "bad" or "sloppy". It just means that there should be a cleaner way of doing this.

lbcoder might be harsh with his words from time to time (ok, always :p ) but his point is valid. He didn't invite a discussion on the validity of this project, he asked for help. If I knew anything about Linux/Android programming, I'd be all over it.
[G1 Android Development] jubeh:
just take a single step back from the throne and realize why a2sd cannot work, jeez

It's dead simple, it's almost stupid. Even though you're still calling a2sd a halfway-hack (which I completely agree with), you're still using it as a basis for a new system that's resistant to errant user behavior. Android was never designed to have it's applications stored anywhere but on internal memory, so if you want to have applications (and/or user data) on sd, you are looking at a modification of the way Android currently handles applications, otherwise you yourself are implementing a halfway-hack to have Android do something it wasn't meant to do.

I'll repeat what I said earlier, what you need instead is a third way for Android to handle applications that ARE stored in sdcard and that the system know they're there. We need to have the package manager be able to handle a temporary app space specifically for the content inside sdcard, all with it's own unique UID (with a space specific to sdcard) and possibly even leave protected apps out of the sdcard equation entirely (though, again, a user with root will still have access to those apps).

As long as Android is based on dalvik/java, there's very little we can do about protecting the code from disassembly, but we're considering here only the standard user with very little techinical knowledge, and any others already have root and are able to pirate at will anyway.

When we give Android the knowledge that apps under a certain space can behave erratically, the system can be prepared by either keeping those apps in a separate space (though this already happens as each app already runs in it's own copy of the dvm) and at most, what we'll get is a force-close of any running processes that are still in memory. Ideally, the "Unmount sdcard" will scan for app namespaces stored on sdcard, then look to see if those processes are in memory, and then kill them before allowing sdcard to be removed (in software, that is).

This limits, then, what we can store on sdcard. We can't store widgets, we can't store services, or content providers that internal apps depend on. We can only have apps that run standalone or depend on services or providers that we know are not going to be removed. In case internal memory fills up, the system could prompt to move apps from internal memory to sdcard, apps that the system (somehow, gotta work on that one) knows that CAN be moved to sd.

Again, note that this is not a2sd, we don't want to move what's supposed to be internal out to sd, we need to make certain, instead, that future android builds have the ability to recognize and handle apps that have been presented to itself in an sd, but I still insist that the best option is asking for larger storage from future hardware manufacturers, and leave the storing of apks on sd for people who just won't (or can't) part with their legacy hardware.
[G1 Android Development] rpcameron:
I'm not sure why this is seen as a huge technical or usability issue. S60 has had this functionality for years. When installing an application, a user was prompted where they wanted to install the application (either phone RAM, removable media, and for those devices that offered them, internal HDD). Then, if the removable media was unmounted and removed from the device, the applications were removed from the menu and inaccessible to the user. If a different removable media card was inserted, the applications installed on that card where then made available to the user and added to the menu when the media was mounted.

If the ancient Symbian platform could offer this functionality, there is no reason why it is unavailable on Android, except for developer hours not being used to implement it. Granted, prompting a user at install-time where the application is to be installed is a very "Windows-like" experience (pardon the parallel, but I feel its the closest analogue), and mobile devices should be as seamless as possible, I wonder if anyone has a more elegant solution.
[G1 Android Development] chrisharang:
To the OP - if your goal really is to solicit cooperation and engage the community in a mutually beneficial way, I think you should really consider your tact. That is all I will say.

- Chris
[G1 Android Development] jubeh:
You know, I was on the wrong about what this project was about; I read through the whole thread (rather than skimming through it) and basically lbcoder is working on exactly the same thing I proposed on how any apps on sd implementation should work. Still doesn't change the fact that I think the idea is a remnant of an age of tired-old-tiny storage (think iPhone, devices should come with abundant internal storage, leaving external storage exclusively for user files) and, although it should be worked on just for the sake of the project, is by no means a necessity, and that the OP is indeed behaving like a prick...
[G1 Android Development] lbcoder:
Actually, no it didn't.

It is extraordinarily simple.

mount -t ext3 /path/to/ext3partitiondevicefile /system/sd

mkdir /system/sd/app

ln -s /data/app /system/sd/app

** thats the basics of it.

The rest of it is just throwing that (plus a filesystem check, i.e. fsck) into the init script.