Android AccountManager and SyncAdapter … WTF?

Ever try to write an application that uses Android’s AccountManager and SyncAdapter to store user credentials?  Wow, what a pain in the arse.

I’ll save you all the ranting and just get down to it.

First, a bit of consolation: writing the code to get your application working with AccountManager is probably one of the more overly complicated things you can do on Android, and one of the most poorly documented features on any cell phone ever.

Google really dropped the ball on this one.  So, I’ll do my best to fill in the gaps.  But be warned, my writing here will be incomplete until I get all my questions answered.  Cause, well, the information I can get is incomplete.

Examples

Google’s SyncAdapter example exists, but there’s no Google documentation that shows you WHY the example was written the way it was.  As with all examples, you must be able to change things to get them to work in your application, so you can’t use them verbatim.  And that’s where the problems come in.

Final concept has a nice example, but again it only solve one type of problem.  And it doesn’t go over the things to avoid when working directly with the AccountManager.

Show AccountManager Output in LogCat

The first thing you’re going to need to do is get logcat to dump AccountManager messages.  You can do this by entering this on your command line:

$ adb shell setprop log.tag.AccountManagerService VERBOSE
$ adb shell setprop log.tag.Accounts VERBOSE
$ adb shell setprop log.tag.Account VERBOSE
$ adb shell setprop log.tag.PackageManager VERBOSE

(source: http://stackoverflow.com/questions/3774282/securityexception-caller-uid-xxxx-is-different-than-the-authenticators-uid )

You can set the log level of any tag with this pattern,  See http://developer.android.com/reference/android/util/Log.html#isLoggable(java.lang.String,%20int)

Notes From The Android Source & Distribution

The best way to get your head around AccountManager, or any part of Android for that matter, is to look at the source, and the distribution packages.  This section covers what I’ve found.

<android-sdk>/platforms/android-X/framework.aidl

This file contains a list of Android Interface Definition Language (AIDL) interfaces that are used within the Android Framework (the operating system components above the hardware).  Within this we find a few key definitions:

interface android.accounts.IAccountManager;
interface android.accounts.IAccountManagerResponse;
interface android.accounts.IAccountAuthenticator;
interface android.accounts.IAccountAuthenticatorResponse;

This is a big clue that IDL bindings are used when talking to the account manager. We should be able to look at the code that implements these interfaces and see what they do.

Attach Android Source to Your Project

This is actually fairly straightforward once you know what you’re looking for.  You simply create a directory, initialize it with the repo command and synch up with the source.  Of course, we’re going to want to synch up with the version of the Android platform that your project is using. Take a look at these links:

Downloading The Android Source Tree – shows you how to get source code onto your machine.  The source lives at kernel.org here.

A List of Android Version Numbers and Names – you will need these to check out the code properly

Here is the command I used to fetch the source code for Android 2.1 (eclaire):


$ cd Android-2.1-eclair/
$ ls -als
$ pwd
$ repo init -u git://android.git.kernel.org/platform/manifest.git -b eclair
$ repo sync

…. lots of output follows ….

Checking out files: 100% (9063/9063), done.out files:   1% (129/9063)
Checking out files: 100% (8503/8503), done.out files:   0% (12/8503)
Checking out files: 100% (429/429), done.g out files:  29% (126/429)
Checking out files: 100% (599/599), done.ng out files:  42% (257/599)
Checking out files: 100% (1959/1959), done. out files:   2% (53/1959)
Checking out files: 100% (1233/1233), done.
Checking out files: 100% (620/620), done.ng out files:  29% (181/620)
Checking out files: 100% (920/920), done.ng out files:  12% (114/920)
Syncing work tree: 100% (162/162), done.

$

Once you’ve checked out the source, take a look at your project in Eclipse.  Associate the Android .jar file with

More to Come …

Nokia Is Keeping Things Interesting

Stephen Elop, CEO @ Nokia

Nokia announced today it was making Windows Phone its primary smartphone platform. If you look at the Nokia stock price you might guess that the company just made a fatal mistake.  But, that’s probably far from the case.

Gartner says Nokia currently has about 37% of the smartphone market share, and Microsoft has about 4%.  Two turkeys may not make an eagle as Google’s VP of Engineering, Vic Gundotra, quips but if Nokia can keep the numbers that high with Windows Phone, they’ll make a lot of turkey dinners for a lot of people.

Supper Is On the Table. Eat While the Food Is Hot.

My attitude toward mobile development is this: any platform, any mobile device, any market, any time. If you’ve locked yourself into a single platform you tend to get worried if your mobile platform of choice isn’t king.  I avoid that trap completely by mastering as many platforms as humanly possible.  If it computes and you can hold it in your hand or embed it, I’m interested in it.

With Nokia/Microsoft blending forces, it feels as though me and my clients just gained a few billion potential customers.  Hey – the more mobile marketplaces and platforms for me to write software for, the better.  Nokia and Microsoft in effect are going to open up more mobile software markets globally.  Nokia already has a very strong global distribution and sales network for cell phones.  And both companies have the ability to host and manage vibrant mobile software marketplaces to the world’s masses.

I know that no matter what, regardless of the platform that’s “hot”, I can literally turn around in my chair at work, look at my co-workers and know that a software product can be written for it.  I work daily side by side with crack iPhone and Windows Phone developers.  As a team we round out quite an option for people wanting to get mobile software written: Android, iPhone, Windows Phone, Blackberry, WebOS, Symbian … you name it.  Including devices that aren’t even on the market yet.  Elop and Balmer hinted at their future hardware platforms as well, but that’s another story.

A 100,000 Cooks Are About To Show Up.

In working with Nokia, Microsoft will garner the focus, over time, of more than 100,000 Nokia workers who will want to keep Windows Phone alive.  They’re going to keep the Windows Phone software marketplace alive as well.  And that’s a good thing all around.

And to Elop’s credit, he hasn’t handed the keys to the kingdom over to a Microsoft platform completely.  Nokia is going to keep its own projects like Meego and Ovi alive.  Who knows ….

we may even see a version of Qt available for Windows Phone in the near future.  Now that would be pretty cool.

Why Nokia and Microsoft, You Ask?

That was seemingly a big question revolving around today’s press conference, and David Murphy from Mobile Marketing Magazine asked just that at four minutes, eight seconds (04:08) into the presentation.  Why not Android, he simply asked.  Elop had an answer of course, but it was just as telling about Google as it was about Nokia’s hardware platform.  Elop had this to say:

If we tipped over into the Android ecosystem and there was a sense that that was the dominate ecosystem at that point, the commoditization risk was very high:  prices, profits, everything being pushed down.  Value being moved out to Google essentially which was concerning to us.  So the Microsoft option represented to us the best opportunity to build and lead and fight [emphasis his] through a new ecosystem that we take into the marketplace.  Remarkably complimentary assets that in totality is going to offer consumers tremendous choice and a great option in the marketplace.

This tells me a couple things which I was surprised about, and which Elop and Balmer reinforced at various points in the discussion.

First, Nokia simply seems to have gotten a better deal in working with Microsoft.  There were concessions made on both sides.  Yes, Nokia is going to pay licensing fees to Microsoft for the platform.  But at the same time, there seems to be an arrangement worked out where Microsoft will be also sending money back to Nokia to get access to Nokia’s hardware and software innovations.  Very interesting.

Second, “Remarkably complimentary assets” to me is a code phrase for “Nokia knows its hardware stack limits its choices of OS.”  Nokia can’t afford to choose an OS that won’t possibly work on it’s limited hardware stack.  That would be worse than anything.  I’m grasping at straws here, but it’s possible.

Turkey Dinners Are O.K.  But TurDucken Is Just Wrong.

Put the wrong OS on Nokia’s hardware (current or planned), and you’re likely to get something equivalent to turducken.  Something that technically can be made but just plain sucks.

TurDucken

Elop seems to recognize that Nokia is forced to put a new operating system on its hardware now, and I mean right now, that will function and function well.  It’s very possible that the other platforms Nokia was considering would have demanded too much performance out of Nokia’s hardware to run.  An entire software ecosystem after all, demands a lot of a mobile device.

Whenever I hear an executive at a cell phone OEM speak about fitting a complimentary OS on top of the available and planned hardware, it tells me that the executive is aware of the limitations of his company’s hardware.  That’s pretty smart and realistic.

Time will tell if all this is the right decision.  As for me, I’m just glad to have another mobile marketplace to write software for.

—-

Image sources: wikipedia, newsmild.com

Some Mobile Software Product GPS Best Practices

Here are some GPS best practices I’ve put together for Android.  It can apply to other phones as well.

GPS Failures

My uncle, Gary Barett, is a PhD in electrical engineering and a GPS engineer as well.  He’s a really sharp guy and available for hire, BTW (if you need a GPS expert let me know – I’ll hook you up).  During his career, he spent a lot of time working on GPS when it was relatively new.  Gary has, in his career, spoken with one of the few people at the DoD who really understands GPS. So, when it comes to GPS he really knows his stuff.  Here’s what I learned from Gary about some common reasons why GPS fails.

1. Antenna Movement.

GPS antennas work on phase shifting (look it up if you don’t know).  GPS transceivers and their antennae are very sensitive to movement.  So, if your GPS unit is on a boat, a buoy, a bouncing car, or you wave around your GPS enabled phone like an excited Italian trying to give driving directions, you can loose your signal.  Loose your signal enough times, and the transceiver will turn off for long periods of time or do a cold reboot.  You know you have this problem if your GPS signal suddenly disappears and the GPS antenna won’t latch on again for long periods of time (or sometimes until your phone gets rebooted).

2. GPS Dead Spots Always In the Same Place (Phase Shift Issues).

Most people know that a GPS transceiver needs at least four satellites to get any kind of a fix.  But few people know that there are actually GPS dead spots that remain in the same place on the earth’s surface.  Intuitively, we know they’re there in places where there’s no line of sight (like an urban canyon).  But, few, if any of us are ever told that even on flat ground with a clear line of sight there can be dead spots.

Here’s why.  In order for your GPS transceiver to detect a satellite, the signal from the given satellite must be strong enough for the transceiver to pick it out of all the background noise.  The way the GPS transceiver detects a signal however, is through detecting phase shifts in the satellite signals.  Too many satellite signals canceling out or distorting or too similar to each other will make it hard for the transceiver to know what satellite is what.  So, the transceiver just gives up as if there were no satellites were there.

But, you might ask, if the earth is rotating and the satellites are always moving, how come the dead spots never change?  Simple.  The GPS satellites, even though they are moving, always follow the same path in space.  There are places below the constellation where the satellites always converge in just the right spot to cause enough of a phase shift interference in the same spot.

This explanation was the answer to a long standing dilemma I had at my previous company, Root Wireless.  During testing, we showed that cell phones always just seemed to die in a particular spot during drive tests, and then not pick up a GPS signal for many minutes (sometimes 20-30).  What happened most likely, it seems, is a particular geographic location always was washed in GPS signals that overlapped just enough to cause phase shift problems.  This one spot confused the cell phone transceivers on different cell phones.  The transceivers thought the satellites were missing, and after trying again and a gain, they just gave up.

You know you have this problem when you drive the same rout many times and your GPS always looses it’s fix in the same spot, regardless of day, weather, or other factors.

3. Satellite Maintenance.

Satellites need to undergo routine maintenance.  It’s common for a satellite to be shut off during a maintenance cycle.  This can cause you to spontaneously loose one or more satellites.  A suddenly disappearing satellite can confuse your GPS transceiver.

4. It Could Be the Russians.

Probably the coolest explanation I heard from Gary had to do with espionage and The Cold War.  When the Russians built their GPS constellation, they did two things. They put up their own satellites, but they also tried to use our own satellites against us.  The idea, apparently, was that the GPS signals from the Russian satellites would somehow overlap our own signal (“piggyback”). This apparently served two purposes.  First, it allowed the Russians to use the freely available signal to guide their own ICMBs and other weapons.  After all, who needs three meter accuracy to target a city with a nuclear missile?  Anything within a few thousand feet will do nicely thank-you-very-much.  Second, it gave the Russians the opportunity to confuse our own GPS sensing equipment by spoofing our own GPS signals.  No better way to cause your GPS transceiver to go haywire.

Some GPS Best Practices

Here’s some additional information about some GPS best practices you might find useful.  Whether your a developer, product designer, or you just simply have your head in the sky about what GPS  can and cannot do, this may help.

1. Treat GPS Transceivers as Phantom Users of Your Applications

GPS transceivers live to feed data into your application. If you treat the GPS service as if it were another user competing for input time and screen space on your cell phone, you’ll write software that co-exists with GPS in peaceful ways.

2. If I’ve Told You Once ….

GPS is a line of sight technology. It doesn’t work indoors or in canyons. If you get GPS data when you’re indoors, it’s simply because your cell phone got the location from another source (e.g. a network server).  There’s no sense in trying to get the GPS to put out if you don’t get a solution.

3. Cell Phones Aren’t Personal Computers or Servers or Dedicated GPS units.

Using the GPS requires a thread.  Cell phones don’t usually handle multi-threading well, even though the capability is there to do background processing.  Be overt about your GPS usage in the user interface.  Design your GPS application around a single thread or design well-thought out pre-emption.

4. Decide Early on What Your Performance Envelope Is.

Decide how accurate you need a fix, how often you need the fix, and what conditions you need the fix in.  That’s your basic GPS “performance envelope.”  If your product designers want to use GPS outside that envelope, then they need to rethink their requirements.

5. If It Walks Like a Duck, It’s Ain’t Always a Duck.

GPS readings from the network are not the same as solutions from an antenna.  Know and talk about the differences.

6. GPS Chipsets and Transceivers In Cell Phones Are Flakey

… even in phones of the same model.  One cell phone may work better than another.  So, don’t “rely” GPS working too much.  They’re either working or not. And, expect them to magically go offline at any time. As the FAA can tell you, GPS receivers on airplanes are much different than the ones in your phone.

7. Use GPS as Infrequently as Possible.

The less your application uses GPS, the happier your user will be.  Stick to a bare minimum.

8. Avoid Spying and Spy-Like Behavior.

Cell phone GPS is not a tracking tool like the one Batman uses to tail bad guys.  Off-shipping GPS data from the cell phone should be avoided if possible.  Nobody likes a peeping Ron.

9. Keep GPS In the User Command and UI Loop.

A quick peak at your handy thesaurus will tell you how you should make GPS appear on your app.  Make it

accessible, barefaced, bright, clear, clear as a bell, conclusive, conspicuous, discernible, distinct, distinguishable, evident, explicit, exposed, glaring, in evidence, indisputable, lucid, manifest, noticeable, observable, open, overt, palpable, patent, perceivable, perceptible, plain, precise, prominent, pronounced, public, recognizable, self-evident, self-explanatory, standing out, straightforward, transparent, unconcealed, undeniable, undisguised, unmistakable, unsubtle, visible

… you get the point.

10.  For Some Phones, GPS is Vaporware.

Manufacturers may promise, but you must prove on each phone that GPS works as advertised before you design your products around it.  This means testing GPS on a particular make/model of a phone on a specific carrier.

11.  Time to First Fix is Always Slow.

If it’s not, then you didn’t get the first fix.  First fix can take minutes.

12. 3′

One meter accuracy is the best you can hope for.

13. Balance Accuracy with Time

The more accuracy you want from your fixes, the longer it take to get that fix.  And the harder it is to keep getting those fixes.  Simply changing your accuracy requirements to 20 meters can save you a lot of headaches.

14. GPS Fades In and Out, and Sometimes More Out than In.

GPS comes and goes.  Using an accelerometer is a good way to track your location when your GPS goes kaputt.

15. Allow the User to Use a Usable GPS Antenna

GPS antennas in cell phones are lame.  Always detect alternate GPS sources, like bluetooth antennas.

16.  If You Fly with Cell Phone GPS, You Die with Cell Phone GPS.

GPS doesn’t kill people.  But, GPS users navigating planes with cell phone GPS units can.  Cell phones should never be used for flight navigation.  If you write an airplane navigation tool on for a cell phone, you could be contributing to someone’s death.

17. Papers Before Positioning

Keep up to date on GPS research and papers.

18. Network GPS Isn’t Available on All Phones.

See #10.  But, if the cell phone you target can see a web server, consider setting up a server based location lookup (e.g. Secure User Plane Location – SUPL).  There are many servers out there you can set up yourself.

A Tegra Blog Entry

I wasn’t able to achieve it last night, but tonight I post this blog directly from the Tegra development board.  I wasn’t able to use the Tegra development board to post last night simpy because I had not inserted an SD card into the available slot.  Now, with that in place, the browser works great, and I’m able to use this wonderful little computer as a very functional device.

A Most Important Posting

This posting is perhaps one of the most important postings I have had in a long time. It’s just like any other posting, except for one thing. I am writing about my new Android development platform: a “Netbook Device Grade”, Nvidia Tegra Development Kit, running Android 2.2.

I ordered my developer kit from Nvidia a couple weeks ago, and after waiting patiently for the device to be built because it was on back order, and a whole week of un-necessary delays by Fed Ex, the kit finally arrived today.

So, naturally when I got home I had to set it up and turn it on.  With a standard VGA cable, I was able to connect the board to my 36″ television and take a few pictures:

The first picture shows how Android looks on my 36″ television.  The paper taped to the television is for scale and reads ‘Android ™ on my 36″ TV‘. The second picture is the Nvidia Tegra development kit all hooked up.  The debug board is not connected.

The Nvidia Tegra development kit is a great product.  Is it worth the price? Sure – especially considering it’s giving me a jumpstart on non-phone Android hardware, and especially because I’ll be able to build a case for it and use it as a notebook/portable computing device.  The only hurdle I had to get through, really, was Nvidia’s approval process to become a registered developer.  But, I figured since I do Android development full time for a living, it would be fine … which it was. 🙂

And, I am glad to be working with Android on some hardware that’s not only a step up from a cell phone, but a dual-core step up (Tegra is a dual core processor).

I did notice a couple things about the board, that you might want to be aware of if you plan on venturing into Tegra waters:

  • The ribbon cables are delicate.  After flashing the ROM, I tried to unhook the companion debug board from the mainboard.  I accidentally pulled too much on the ribbon cable and the plastic end of the ribbon cable literally came apart in my hands.  No damage to the board though.
  • It’s still not a PC. The beauty of the Android operating system is just that.  Android does simple things, and does them well.  A straight forward OS on good hardware like the Tegra development kit is just the ticket for scalability.  It’s all about being simple.
  • Browsing and networking is sensitive. I haven’t benchmarked the board or the software yet, but the Internet browser sometimes sticks and becomes unresponsive.  It could just be my faint wireless signal.  This could also be because I haven’t installed an SD card either so the browser might not be able to cache properly.
  • There’s terminal access right on the device. Using the dev tools that come pre-installed on the flash image, you can telnet to the local device and peruse the file system.
  • There’s limited software on the device (thank GOODNESS). The last thing I wanted to put up with is a bunch of pre-loaded software that just gets in the way of development.  This board comes pre-loaded with a minimal software set that is geared toward developers.  It is a development kit, after all.  Very nice.
  • Installation of the OS was a breeze. Just follow the instructions on the website and on the documentation that comes with the development kit and you’ll be fine.  Total setup took mere minutes.  The majority of that was waiting for the developer tools to download from the Nvidia website.
  • It’s a delicate board. Don’t stress the board.  It’s just a baby and has delicate parts.  Do be careful.

I can’t wait to benchmark this board and see what it can do.

Overall, I give the Tegra development kit two thumbs up.  Looking forward to some dual-core Android development and mucking around in the board support packages.

Good Review on The Verizon iDroid

http://www.engadget.com/2009/10/30/motorola-droid-review/

There are a couple of things you notice about the droid when you first pick it up.  The first is the weight – it feels good and solid in your hand.  That’s important because I have large hands.  It just “feels” like a solid phone the first time you pick it up.  The second thing you notice is the clarity of the screen. It’s just amazing.

My impression first off is that this is the first cell phone that has crossed into the “feels like a PC” device.  It’s setting yet more standards for mobile computing devices in ways that up until now only the iPhone could define.