The Search for an ideal iPad Case

If you bought an iPad and would like to get some protection for your $500 investment, whats the most ideal case for you? Do you want a sleeve, case or portfolio version? I'm trying to figure that out myself.  I've round up a short list cases from a few manufacturers for a review and will give you my honest opinion for each.  Here are the ones I've arranged thus far and will work on getting more for a complete coverage.  Over the next few days, I"ll be working on reviewing each one and post the my reviews below  Once a review has been put up, I"ll link it to the product below:

Griffin Elan Sleeve for iPad - ($49.99 Griffin)
Griffin FlexGrip for iPad - ($34.99 Griffin)
Griffin Elan Passport for iPad - ($49.99 Griffin)
colcasac for iPad - ($34.95 colcasac)
Apple iPad Case MC361ZM/A - ($39.99 Apple)

Android on iPhone 3G

I wrote a piece about this that PC World was nice enough to run.

Click here to read the PC World article for more details!

Here's the video demo that I put up:



Thanks to ricky26 and bluerise for their time on the multitouch, many others who worked on openiboot, and my friend Alisa for the graphical changes (visit her site at galiaxy.net)

Be Careful With Content Providers

The notion of a Content Provider is central to getting things done in an Android application. This is the mechanism used to expose many of a device's data resources for retrieval and update: Contacts, media store, bookmarks, phone-call log, and so on. It’s hard to find an interesting Android app that doesn’t either use or implement (or both) a Content Provider.

There’s nothing magical or terribly surprising about Content Providers - you address them by Url, query them with SQL, and iterate them with a Cursor. They do what they say they do and get out of the way and they’re easy to create and use. But there’s a common anti-pattern, a way to misuse them that can potentially get your app into trouble, and maybe we’ve made it a little too easy.

The Content Providers that the Android framework gives you are described in the SDK’s android.provider package summary. For many of them, the framework provides helper classes of one sort or another, to help automate common chores and provide symbolic names for useful constants.

The problem is, there are more Content Providers in the system than are documented in that package, and while you can use them, you probably shouldn’t. They’re there because some of the Google-provided apps use them internally to access their own data resources. Because Android is an open-source project, it’s easy enough to find them just by running shell commands like find and grep over the source tree.

(By the way, searching the source tree like this is an excellent idea, something that probably every serious developer does regularly. Not 100% sure of the best way to write code to display a record from the Contacts database? Go ahead, have a look at how the built-in app does it; even better, steal some code; it’s perfectly legal.)

Back to Content Providers. For example, there’s one inside the built-in Messaging (A.K.A. texting or SMS) app that it uses to display and search your history. Just because it’s there doesn’t mean you should use it. The Android team isn’t promising that it’ll be the same in the next release or even that it’ll be there in the next release.

It’s worse than that; someone could ship an Android device based on the current SDK that follows all the rules but has its own enhanced messaging application that doesn’t happen to have such a Content Provider. Your app will break on such a device and it’ll be your fault.

So, go ahead and look at the undocumented Content Providers; the code is full of good ideas to learn from. But don’t use them. And if you do, when bad things happen you’re pretty well on your own.

Creating a WM8991 driver

Thought it might be interesting for people to take a peek at how we work.

As I stated in the previous blog post, it's necessary for us to figure out the WM8991 audio codec before we can call from the baseband (or listen to music). This is an interesting task because while there are datasheets for the WM8991 codec, and a Linux driver for it, those cannot be used immediately since it doesn't tell us where the inputs and outputs of the chip are connected to, and what protocol and clock divider settings the iPhone uses to talk to the chip (and must be configured on the chip). Those things are purely implementation specific.

In order to extract those settings, we need to be able to see those settings while the iPhone OS kernel is up and running and sound is playing. The chip does not use MMIO, so the register settings cannot be directly peeked at through /dev/kmem... but we're on the right track. Instead, I2C is used to communicate with the codec for setting those registers. It turns out that since some Wolfson codecs do not allow reading from the codec registers (only writing), the operating system has to "remember" what values registers are currently set to. That is, they are cached by operating system?

Where are they cached? Well, a quick look at the disassembly shows us some code that does the following (in pseudo-C)


if register > *(this + 0xA0)
return 0

return *((uint16_t*)(*(this + 0xA8) + register * 2))


Basically, we see that the class member at offset 0xA0 contains the total number of registers accessible on the Wolfson codec, while member 0xA8 is a pointer to an array of 16-bit values that represent the current values of those registers!

Now we seem to be home free... except for the fact that IO Kit C++ objects are dynamically allocated on the heap at runtime and there is no way to tell using static analysis where they will be during a particular boot of an operating system. How will we find the location of this C++ class (AppleWM8991Audio) so that we can peek at those values?

The answer is that every object in the IOKit subsystem is anchored to the IORegistry tree. You can actually take a peek at the tree from userland with the ioreg -l command. Every single node you see corresponds to a C++ object. However, the trouble is that there is no userland call to extract the in-kernel addresses of those objects... and that's what we need to be able to use /dev/kmem to peek at the right places.

Fortunately, the root of the IORegistry is pointed to by a constant, and it is possible to traverse the IORegistry manually from the root (provided you know the layout of all the C++ classes!). This is exactly what I wrote a utility called spelunk to perform: use /dev/kmem to manually traverse the IORegistry and find the in-memory instance, instance size, and vtable location of all of the objects in the IORegistry. Armed with this information, one can use dd and /dev/kmem to peek at the state of any of the objects inside kernel memory.

I made a series of dumps: registers-call-headphones, registers-call-speakers, registers-max-headphones, registers-max-speakers, registers-min-headphones, registers-min-speakers. Here is a diff of min-speakers and max-speakers, just to show you what we're looking for:

--- hex-registers-min-speakers 2010-05-04 15:44:19.000000000 -0700
+++ hex-registers-max-speakers 2010-05-04 15:45:39.000000000 -0700
@@ -2,7 +2,7 @@
 00000010  20 80 20 80 00 00 c0 00  c0 01 00 00 00 01 c0 00  | . .............|
 00000020  c0 00 00 00 01 00 00 17  00 10 40 10 00 00 04 08  |..........@.....|
 00000030  8b 00 8b 00 8b 00 8b 00  b0 00 b0 01 66 00 22 00  |............f.".|
-00000040  f9 00 f9 01 00 00 03 01  57 00 00 01 ec 01 00 00  |........W.......|
+00000040  f9 00 f9 01 00 00 03 01  57 00 00 01 ff 01 00 00  |........W.......|
 00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00000060  00 00 00 00 00 00 80 01  00 00 00 00 03 00 00 00  |................|
 00000070  00 00 08 00 00 00 00 00  87 00 85 00 fc 00 00 00  |................|

So it's fairly obvious how volume control for the speakers are done. Anyway, hopefully we can plug in these values, use the current i2s drivers, and audio will work!

Taking the Android Show on the Road

[This spring, the Android Developer Relations team (where I work, too) went on the road round the world with boxes of phones, their laptops bulging with slide-ware. Here we’ve combined write-ups from Billy Rutledge (who leads the Android evangelism team at Google HQ) and Reto Meier, who has a desk in London and wrote the book on Android. Featuring Europe is a little unfair, there are a ton of stories from Asia and North America too, but we wanted to keep this reasonably short. - Tim Bray]

Introduction

Billy: The Android Developer Lab (ADL) events are sponsored by Google to help drive developer interest in the Android platform and increase the quality, as well as quantity of creative, innovative applications in Android Market. This Android Developer Relations tour covered 18 locations around the world; we met with over five thousand enthusiastic Android developers and were thrilled to see the energy and creativity behind your applications.

Reto: The European leg of the Android Developer Lab World Tour consisted of me, Billy, and intrepid local volunteers covering eight labs in eleven days across six countries.

Some of the venues weren't like some of the others.

The goal of the tour was to meet and support local Android communities around the world, get developers excited about Android, and inspire them to create the next generation of innovative mobile applications.

Billy: In these sessions, we tried to help new and experienced developers move forward with their application plans. The core topics included:

• Status of the Mobile Web

• Android Opportunity for Developers

• Android Market Overview

• Android SDK Key Features

• Code Labs ranging from HelloWorld to Threads to LiveWallpaper

Reto: The odyssey began in the London Google office, three labs over two days that played host to nearly 200 developers. Our surprise gifts arrived minutes after our first session started - a close enough call that our “there’s a package you need to sign for - any idea what it is?” charade was unscripted and only partially contrived. The heart palpitations were entirely real. London is home to some great Android developers including the teams behind ADC2 winners PlinkArt and BuzzDeck.

After London we battled ice and snow in Stockholm, where Anders Bond told us why Android is a good match for Spotify, and enjoyed the sound of 100 Swedes spontaneously erupting in applause.

In Paris 200 experienced community members joined us for two events at La Cantine. Speakers from FRAndroid, Sfeir, and Diotasoft covered everything from OpenGL development using the SDK to using AppEngine to create scalablends for your Android apps.

The Berlin event was huge, with over 150 developers travelling in from all across Germany. We saw demos including multi-touch pong, a Live Wallpaper of the changing Berlin skyline, and an app that showed us where to find (and rate!) the nearest public toilets. The night ended (in the small hours) with a private tour of c-base, an experience not to be missed.

Universidad Rey Juan Carlos made us feel very welcome in Madrid. Over 200 developers from across Spain (and Portugal) were in attendance including more winners of ADC1 (Biowallet) and ADC2 (SweetDreams).

Lessons Learned

Billy: Developers have matured to the point where they don't need to be convinced, they hunger for more technical details. While the intro level topics were well received, most developers have advanced beyond this point and seek guidance on more in-depth topics.

Reto:

• It’s possible for one person to carry up to four boxes each containing ten Nexus Ones at a time.

• You should not try to carry more than three boxes of Nexus Ones if the conditions are icy. Right Billy?

  Billy: Absolutely!!! :)

• Announcing free smartphones to a room of developers always results in a spontaneous round of applause.

• European mobile developers are smart, enthusiastic, and already building the next generation of epic apps for Android.

Billy: Post event series, we opened a volunteer survey to help us guide future efforts:

• 78% of developers rated the event 4+ stars (of 5 stars)

• 79% of developers say having Google engineers on hand is "extremely important"

• 69% of developers say it is "extremely important" to see more test devices at future events

Looking Forward

[These are still at the planning stage, nothing here is a promise. - Tim]

Billy: The Android Developer Relations team plans to lead future Android Developer Lab events in 2010, building on the feedback from the February events. These future events will focus on deeper technical subjects, expecting the attendees to have a basic understanding of the Android platform. We will post the beginner material on-line as a prerequisite.

While it's impossible for us to reach all locations, we'll look to cover the key locations where Android devices are available.

Reto: I hadn’t even made it back to London when the requests started to roll in. Given the success of this tour I don’t imagine it will be too long.

It’s always a great experience meeting the Android developer community, we look forward to seeing you again soon!

Orange and Vodka - mixing mobile networks

Orange and Vodka - mixing mobile networks(shaken, not stirred).Good title for a book or article that heading. I thought this would be a useful post regarding the unusual occurrence of roaming onto a forbidden UK network from the home UK network.These screenshots record an event that happened on my wireless broadband. In the area I was located at the time Orange provided GPRS at 56K but download

Cell network association and SMS on iPhone 3G

This is just a small, incremental update. It looks like we're currently blocked on a driver for the WM8991 codec. This is because instead of sound data that should come out of the speakers directly to the baseband, the Wolfson codec now controls the speaker as well on the 3G. This is a significantly more sane design than what the 2G had, but it causes us some complications.

First, now a WM8991 driver has to be written before we can get any sound out of the device. This is contrary to the 2G where we can test the i2s functionality of the SoC relatively independently.

Second, in order to make or receive calls with the iPhone 3G, the WM8991 driver must be written and cooperating with the baseband. This is a significantly more complex arrangement than on the 2G, where that functionality can be controlled entirely through the baseband.

However, this is still all not very hard. If we had a timetable, I'd say we're "on track". But we don't so don't ask. :P

Also, as a result of this investigation, I can associate to the cell network and send and receive text messages from the 3G now. Of course, I had to port ultrasn0w into openiboot to do it... I had forgotten all about the fact that my phone was unlocked by ultrasn0w until now. :)