Android Development

Due to the current outage of android.git.kernel.org, and the fact that
Google Project Hosting now supports Git, the repo tool is now
available from its code.google.com repository:

http://code.google.com/p/git-repo/

The launcher script is also available as a download:

http://code.google.com/p/git-repo/downloads/detail?name=repo-1.14

So to build android-x86 from sourceforge

wget http://git-repo.googlecode.com/files/repo-1.14
chmod +x repo-1.14
./repo-1.14 init -u git://android-x86.git.sf.net/gitroot/android-x86/manifest.git -b gingerbread-x86

move repo to /usr/bin

sudo mv repo-1.14 /usr/bin/repo

and then sync and build as usual

This is basically what was going through my mind as I watched Apple’s promotional video for their latest update for the iPhone, iPad and iPod touch, iOS 5. I know that I’m not the only person that can see that Apple just copied directly from Android and Windows Phone, there’s no denying it. I hope that this video can create an obvious visualisation of the features so blatantly stolen from their competition. Please thumbs up and comment.

Article by  JR Raphael (@jr_raphael) 

I’m lucky enough to get the chance to use and review a wide variety of Android phones. In my gadget-exploring adventures, it’s hard to avoid noticing one common and very unfortunate thread:

Nearly every phone is made less appealing because the carrier loaded it down with bloatware.

Bloatware, if you aren’t familiar with the term, is all the extra crap companies stuff onto phones — crap you probably don’t need, don’t want, and won’t use. It’s been around since long before the advent of smartphones (hello, Windows), but with Android, the carriers are really starting to get greedy.

Take the recently unveiled Samsung Galaxy S Epic 4G Touch. I’ve spent the past week getting to know the phone and have generally been quite impressed (see my full review for more). But amidst the device’s fantastic features, Sprint has burdened users with 10 pieces of superfluous software — many of which are unnecessary pay-to-play programs like Sprint ID, Sprint Radio, and TeleNav GPS.

Sprint isn’t the only guilty party, of course; pretty much every carrier plays this game. I counted 20 (!) pieces of unremovable bloatware on Verizon’s recently released Motorola Droid 3 device. These days, Google’s “pure Android” Nexus phones are about the only ones guaranteed to be bloat-free.

Here’s the cold hard truth: To carriers, smartphones are more about making money than delighting users. And nothing’s going to change that. Bloatware gives carriers a way to squeeze extra bucks out of customers, either by striking deals with developers to have their apps preloaded or by bundling in their own second-rate subscription services in the hopes that folks will sign up. Android’s open nature means the carriers are free to modify the software as they see fit — and let’s face it, that’s certainly no small part of the platform’s appeal to them.

But here’s where I think we could reach a more reasonable middle ground: Right now, carriers set the majority of their preinstalled programs to be system apps, which means there’s no way for a user to remove them from the phone (short of hacking the device, but that’s not something a typical user is going to do). Some of the players are getting a little bit better in this regard — Sprint has started making some of the bloatware on some of its phones uninstallable, including about half the crap it put on the Epic 4G Touch — but a half-assed effort here and there isn’t enough.

So carriers, hear me out: Keep preloading your wares onto the phones, if you must — but start respecting your users enough to allow them to uninstall what they don’t want. You still win: You can make the deals with developers and get paid for preloading their apps on your devices. You can keep bundling in your own programs and services, too, making sure every user sees them and has the opportunity to sign up for them.

If a user isn’t interested, though, he can choose to remove the program. Surely you can make enough money with your preloaded app deals, even if the apps aren’t baked into the system as part of the arrangements. And surely you realize that if someone wants to uninstall something right away, he wouldn’t have used it in any case — even if he had been forced to leave it sitting on his phone for two long years.

Come on, carriers: Android is an open platform, and that opens it up to a lot of interesting possibilities. Don’t take that asset and use it to turn your phones into virtual junkyards. Trust me: A little respect for your customers will go a long way.

[See also: It's time for the baked-in Android UI to die]

posted by Thom Holwerda

Ever since Honeycomb’s release, Android has had two versions out in the wild (well, if you disregard the non-current versions, that is). The next major Android release, Ice Cream Sandwich, is supposed to fix this problem by having one single version of Android for both phones and tablets. Google now has a blog post up which presents some options for developers to prepare their applications for Ice Cream Sandwich.

Right now, several developers have hard-coded their Android tablet applications to certain screen sizes, but when Ice Cream Sandwich arrives, which will run on all screen sizes, developers will have to adapt their applications. Google presents two options: limit your tablet application to certain screen sizes (preventing them from being installed on smartphones), or make sure your application works on all screen sizes (the preferred option, obviously).

The first option is straightforward – it’s the second one that’s interesting. For the action bar currently implemented on Honeycomb, developers should face few problems – provided they used the official implementation, instead of building their own. “As long as you’ve been using the framework’s implementation of ActionBar for your tablet app (rather than building your own), the conversion from tablets to handsets should be painless,” Google explains, “The Android system will do the work for you; all you need to do is ensure that your action bar design is flexible.”

Of course, if you use your own action bar – or don’t use it at all but use some other means of navigating through your application – then you’ll have to do some work yourself. This seems like a pretty good carrot and stick to use the official implementation. In the end, it’s better for users, too.

As far as the actual content of your application goes, there are two ways to adapt Honeycomb tablet applications for smartphone screens. First, “for any screen in which your tablet version displays multiple fragments, use the same activity for handsets, but show only one fragment at a time – swapping the fragments within the activity when necessary”.

The second option is a bit more involving. “Use separate activities to host each fragment on a handset,” Google notes, “For example, when the tablet UI uses two fragments in an activity, use the same activity for handsets, but supply an alternative layout that includes just one fragment. When you need to switch fragments (such as when the user selects an item), start another activity that hosts the other fragment.”

This second option is a lot of words with Android-specific terminology, but the following image puts it in a way we can all understand.

This second option is a bit more work, Google notes, but is the better solution. “It might be a little more up-front work, because each fragment must work well across separate activities, but it usually pays off,” Google notes, “It means that you can use alternative layout files that define different fragment combinations, keep fragment code modular, simplify action bar management, and let the system handle all the back stack work.”

Sadly, the Ice Cream Sandwich SDK hasn’t been released yet, so you can’t test your adapted code just yet. In spite of this, if you have Honeycomb applications out there, be sure to follow Google’s advice and guidelines, since it will only make the lives of your users easier.

The iDroid Project, a group that aims to fully port Android OS to Apple’s iOS devices, has just taken to the stage at MyGreatFest. Here’s what the team behind the project had to say.

Back in 2008, the project initially began under the name of the “iPhone Linux Project.” This project aimed to boot a Linux kernel, and by the end of 2008, this aim had been achieved. The year after, the hacker behind the iPhone Linux Project surprised everybody by presenting a working first-generation iPhone running Android OS: The iDroid Project was born.

Since, the iDroid Project has been working hard on creating a full port of Android on other iOS devices.

Currently, iDroid has been downloaded hundreds of thousands of times. However, there is still work to be done. The iDroid Project is concentrating on bringing iDroid to the iPhone 3GS and iPhone 4, and in supporting other versions of Apple’s mobile operating system.

The really impressive thing about iDroid is that users can run Android and iOS on the same iPhone, side by side, meaning it’s kind of like Boot Camp for OS X.

It’s definitely an interesting project, and something we’ll be keeping an eye on. For more information on the iDroid Project, head on over to its official website.