After a month of banging my head on the ICS camera, I can safely say it’s getting very close. NOT DONE, but close. And trust me, when it’s ready — I’ll announce it to everyone by every means possible. You will know.
WHAT TO EXPECT DURING THE DROID 3 CM9 BETA?
For the next phase I want to take on various phone features while cleaning up the bugs in the build (mostly audio routing related). Stuff like:
– Dock Audio
– HDMI output
– And support for both the XT860 and XT883 as smaller sub-patches to be done after flashing the main CM9 .zip
XT860 Status: XDA-user Rick#2 has already gotten the XT860 to run ICS w/ 3G data, and I’ll be using his work to do the XT860 patch. For now you can download his entire .zip of Alpha #5 with working 3g here: http://forum.xda-developers.com/showthread.php?t=1465297
XT883 Status: I need the same thing done for the XT883. That patch should probably contain a build.prop and RIL binaries at the very least.
The site has REALLY taken a beating over the last 2 versions of CM and several releases of Safestrap. The comments on each page have grown quite long, and most are out-dated.
So, over the next few days I’m going to restructure the blog to cleanup each of the pages. Some of them will disappear entirely and/or be combined together, while other pages will have all of the comments cleared out.
– Camera is getting close, so watch for the incoming beta sometime in the next week.
– Don’t be surprised when the comments and some of the pages on the blog disappear or get merged.
– Expect to see some cool stuff in the Beta.
PS. IT’S NOT PERSONAL! IF I DELETE YOUR COMMENT AND YOU WANT TO REPOST IT, PLEASE DO.
I know many of you are wondering: “How is the ICS camera coming?”
Well, here’s the update (I posted this on XDA and felt that maybe it was worth putting her as well).
Few days ago, I completely stripped out the dev/ion references from the camera code and was starting to work through a rewrite using our version of the memory tiler built into the kernel (TI memmgr1.0) However, that caused some instability in the system which you can see in Alpha #4 at times. Also, it hung the media_audio service out on the boot up which is why it’s taking so long to boot currently.
Today, I reverted all of those changes, and instead built a ion_driver kernel module. The /dev/ion device is the ICS interface for Android to work with the memory tiler at the kernel level. The module includes an update to the tiler / dmm driver source as well (i named them tiler2 and tiler2_dmm). In the kernel module, all of the ion driver tiler calls are directed to the new tiler2 interface instead of the original one built into our kernel.
Right now I’m testing / debugging those modules.
If loaded on system boot, tiler2_dmm.ko, and tiler2.ko modules load fine.
But, I’m working through some missing references on the ion_driver.ko module.
I’ll know more in a day or so as I debug it, as to whether this technique will work.
Worst case: I’ll have to re-write the tiler2 portion as a wrapper of our existing tiler instead of a whole new device as it is now.
TL;DR: Camera needs the /dev/ion device (as does a few codecs) I’m working on a kernel module solution at the moment which has some bugs
ICS presents a lot of new and exciting features, many of which aren’t working in my current Droid 3 build. One such feature was designed as a response to carriers removing the all you can eat data plans which were common to smart phone users. How would you easily manage your data under a plan with a limit?
Data Usage Stats
Today, I finished the kernel modules necessary to make this screen work as intended. And starting with the next release, you can being using it.
This screen is under “Settings” -> “Data usage”. Under current builds, it shows only the total amount used (as a graph and text form underneath).
The screen now correctly allows you to set a warning and potentially a point at which your phone will stop using mobile data. These are represented as yellow and red bars on the grid. Also, not shown in current builds is the breakdown of data usage by application underneath the graph which allows users to quickly identify apps which are using too much data.
The working interface looks like this: