The hardest part for iPhone users (or any other mobile OS user) transitioning to Android is the understanding that Android has very different internal concepts than iOS despite the UI and icons thing.
1. The first thing to understand is that Android apps are modular. They basically consist of an Activity, which is the part of the app that the user interfaces with, and the Services, which runs on the back. Even if the Activity is closed or not run, the Service can continue to run on the background providing for updates and services to other Android apps as well. That's why you don't use task killers. Most of the time you see app Services, not Activities, and when you kill those services, you're not doing yourself and the phone a favor. Services are also the ones responsible for adding additional sync services to the OS, all done without an OS upgrade.
2. The second is that there are kinds of apps in Android that don't exist in iOS, though some may exist also in the Symbian and Windows Mobile worlds. These are:
a. Widgets
b. Live Wallpapers
c. Profile apps
d. Lockscreen apps
e. UI shell apps
f. Task managers
g. keyboard apps (Swype, Swiftkey)
h. Services (Adobe Flash, AIR)
I. Voice action apps
J. Gesture action apps
K. Plugins
3. The third is the capability of Android apps are quite different. Using Services, Activity and View classes, an Android app can have a Widget component that can be displayed separately from the main app. Services allow apps to share information from one app to another. That's why you can send tweets from Twitter for Android to Evernote, or send any picture from the Gallery to Picasa, Flickr, Facebook, etc,. The third capability is that Android apps can be set for background periodic polling even without the main app (Activity) is launched. Again, this is done by the Services.
4. That there are two ways Android apps are constructed. With the SDK, its written in Java, is managed code, and run within the Dalvik VM. With the NDK, it is written in C languages, run as a native, unmanaged code, and outside of the Dalvik VM. The third is usually a hybrid of the two.
Most apps are run as Dalvik, but some apps, usually games and some browsers like Opera Mobile and Firefox, are run as native or as hybrids. By far, Dalvik apps are not affected by the use of different processors on Android phones, but native apps have the potential to be more sensitive with regards to the different chipsets. Again, fragmentation is overrated for most apps but it can be a real reason for some apps that decided to go native.
5. The fifth is that Android apps, at least those that written for Android 1.6 and above, are designed to natively scale. Android apps are not written to fix hardware coordinates (X = 320, Y= 240), but on reference points (X = Xa, Y= Ya). if an Android app is run on a tablet, it won't create a huge black border like an iPhone app on an iPad. Rather, it would scale up to occupy the entire space. While the display is suboptimal, it is better than leaving a huge black border. Some apps cannot go down to QVGA resolutions however. Resolution and density declarations can be made within the app, and the Android Market can selectively filter out devices based on those declarations. Note. Its harder to scale down than to scale up. Native scaling is one particular reason why "fragmentation" on display resolutions is an overblown issue but one should be aware with low end QVGA devices but less of a concern with superphones and tablets.
6. The next is the Security permissions of Android apps. Note when you install an app, it will list down what it can do. Its more than a contract to the user, if the OS detects the app doing something beyond what is declared in doing, it will be terminated and gets reported. An app doing something beyond its stated declared permissions is a good way to get removed from the Android Market and even remotely deleted from handsets by Google. If an app is unknown and the list includes things you are not comfortable with, or out of character with the app's purpose, you don't have to install it. Usually the Dalvik VM creates a protective sandbox around the app.