This is how I introduce Android to teams that are making their first serious non-game app:

1. How to scale the app across all screen geometries:

   a. Let Android choose the layout from among the alternatives you create for different geometries
   b. This means different numbers of Fragment objects can be displayed
   c. This means different functionality can be available 
   d. This means you have to organize functionality in a hierarchy (for the smallest screens) that can be unfolded and flattened (for the biggest screens)

2. Then I get into Activity and how the code that used to be in activities should be organized into Fragment subclasses, and about top-level layouts.

3. Then I get into Relative Layout and how to make your layouts "stretchy" enough that you don't have to specify a different layout for every combination of size, density, orientation, and text size.

4. Now that the coders and designers understand how they fit together in making a UX that "folds up" and "unfolds" I teach the designers how to check in to the client's repos, and how to edit layouts in Eclipse, so they can be responsible for their own work getting into the project and build and run the app to see how their layouts work.

This is still a vast simplification, leaving out things like Android remote methods and high-level (Intent) IPC and how hat affects UX, and numerous other areas where Android is substantively different from iOS's app environment.