Well here's where things are right now.
The GPS is really pissing me off. That's the nice way to put it. A couple of dozen attempts to link in the Froyo libs have failed utterly with either a load that refuses to boot (the worst possible case of course) or one that comes up with no GPS at all. Ditto for attempting to use the Cherry or AndroID libs (both of which are 2.3 based and therefore SHOULD work.) Attempts to use the base Qualcomm GPS drivers in CM7 have failed as well, despite the fact that it should work too.
What I really need is to pick someone's brain that has worked on the integrated GPS in this particular chipset in the past (not someone who has hacked on it, but someone who has access to the actual documentation), but thus far I can find neither documentation of what they did to get it working on the 'net or such a person. This is posing a serious problem for getting this rat bastard operating, as the implementation is mostly-opaque at the driver level (kernel, operating system and application) which strongly implies that most of the "reality" in this implementation is in silicon and without docs you're (mostly) shooting in the dark. Oh by the way, that sucks.
I have accidentally discovered the reason the GPS has such sucky problems in the base load, and it's not good news. AGPS is not being used - at all. That is, the data is not being pushed down to the chipset, which is why the long lock times on a first use; the only sync that is being run is the rough (coarse) position. I'm virtually certain at this point that's the case, which strongly implies there's a problem with the chipset and Motorola intentionally disabled AGPS. If I'm right about that then that MIGHT explain why attempts to link with the CM7 drivers failed so miserably (the chip would come up and see a bird or two but never get a lock) - that is, I might have been "poisoning" the implementation with the AGPS setup attempts.
In any event this is proving to be a MAJOR hurdle.
On the proximity sensor issue there's probably nothing in software we can do to fix it. As Isaac noted we're using the STOCK (Froyo) drivers for those sensors, which means what we're getting now is exactly identical to what we were getting in terms of code returns. The worse news is that turning that off and using CM7's drivers led to "no joy" earlier and I can't reproduce the problem, which implies there's some sort of calibration problem that may be a sensitivity variation issue with the hardware when you boil it all down, and using the Froyo libs will preclude a fix.
Without the GPS I cannot reasonably call this build "Alpha" and start going after the bugs, so until I find a solution to that problem I'm keeping my focus there, as without it we have a dead end and fixing everything else won't lead to a fully-usable result. There have been a handful of other minor fixes (lights in particular, which are now 100%) but there's not much of a point in pushing new loads until I have SOMETHING on the GPS front.
I have no timeline on this right now. One of the problems is that some of my work is coming up with invalid device open attempts (e.g. attempting to open non-existent devices in the code) and others fail during the build with unresolved references to routines that my examination of the code says shouldn't be unresolved. Documentation on this (like most of CM7 and Android in general) is somewhere between poor and non-existent; having done a lot of code development in my years if this was the state of documentation for a commercial project I was in charge of I'd expect to be fired the next morning. Most of my work thus far has required sticking debugging statements all over the code to figure out what the hell is going on so I can trace down where the failures are coming from. In addition the build process itself throws literally hundreds of warnings (typing issues and similar) which is extraordinarily un-cool and says far more about the state of the base Android code than I'd like, and none of it is good. Finally, if that's not bad enough there are dependency problems in the makefiles such that changes don't always force rebuilds of the impacted areas as they should and even a "make clean' doesn't always remedy that problem. This forces me to do a manual clobber of the object directories when I run into problems to ascertain that what I think I'm running into is real and also means that I have problems being sure that my builds are able to be reliably reproduced.
This sort of roadblock simply shouldn't happen in any reasonably-well-documented project, and something of this size and complexity damn well ought to have a fairly complete and accurate chain of documentation as to how the pieces go together, what passes what to whom and by what path, etc. In addition you should be able to rely on the makefiles properly handling dependency chains so a change you make properly propagates through the build process.
None of that exists and most of the previous (e.g. 1.5, 1.6 era) "official" Android documentation has been pulled with a comment left that it's "out of date" - but it has not been fixed and replaced. This state of affairs is a competitive disaster down the road for Google and Android, and that it appears to have been the case for a couple of years now (going back to Froyo at least) doesn't push my buttons in terms of thinking toward the future of Android, but it is what it is and I have to work with what I've got.
As just one example I don't even have a map of the /dev/oncrpc directory structure so I don't know what the CORRECT interface is that SHOULD be opened for the GPS. I could always hard-code around the logic that performs the open calls if I did know, but I don't and thus I can't.
Anyway that's where things are. I'm continuing to work on the build but it's a very frustrating process at this point. So close and yet so far.....
