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.