I primarily program Android and have talked to many other Android programmers.
The primary blunder companies make on doing an Android app is they pretend they're making an iOS app. This is very widespread.
The company has a database. They have a website. They have an iOS app which connects to a web API connected to that database. They have a designer who makes his 2 (or 3?) designs for each iOS form factor.
Then they decide to make an Android app. The web API is usually OK. But it becomes decided that the company will ignore that Android's come in tablets, very small phones with low resolution, phones with very high resolution, "phablets" etc. It becomes decided that the goal will be to make a pixel perfect design (just like for the iPhone!) for the Android phone the designer has, and perhaps the other one the boss has, and then to just pretend that the other 99% of the Android market does not exist.
There is more Android work then experienced Android programmers, so some inexperienced kid right out of college is the programmer on the project, who is easily intimidated by the designer. They proceed this way until weeks and months go by and the CEO realizes the app looks like junk on tablets and most phones, and then blames the programmer for this situation.
Anyone thinking of stepping into a role as an Android programmer should get everyone on the same page about the UI goals before he agrees to work on the project. Especially between you and the designer and whoever your common management is, perhaps all the way to the top. Because the easy way is for the designer to do what he did for iPhone - 2 designs for the 2 phones he has access to, which are pixel perfect (which is completely pointless if it looks like crap on 99% of phones).
This situation arises again and again and again.
If there's any secondary thing, I guess it would be how far back you want to support Android in terms of versions. You really don't want to support something before v3.0 if you can avoid it.
Completely agree. Some of the unhappiest engineers & designers I know are on teams trying to copy the company's iOS app on Android.
We were admittedly in the position you describe: a company of majoritively iPhone users who shipped the web & iOS apps, cleaned up the API and were starting on Android.
We also ordered a range of devices and hooked them up to our Play Store alpha channel so every build had to go through the 3" phone and 10" tablet test.
Finally, it helped to have a couple hard core Android users on the team who could explain why simple features like the 'back' button are truly game changers. There's a good post on some of these differences here: http://paulstamatiou.com/android-is-better/
I do both iOS and Android, but stronger on Android. In addition to the "pixel perfect" nonsense is not actually writing an Android app, and instead limiting it to what is normal on iOS. A good Android app should be a mashup, and it should have pieces that cooperate including outside the app as appropriate. A very quick telltale sign of an iOS port is the list of other interactions being built in (eg which services it can "share" with).
The primary blunder companies make on doing an Android app is they pretend they're making an iOS app. This is very widespread.
The company has a database. They have a website. They have an iOS app which connects to a web API connected to that database. They have a designer who makes his 2 (or 3?) designs for each iOS form factor.
Then they decide to make an Android app. The web API is usually OK. But it becomes decided that the company will ignore that Android's come in tablets, very small phones with low resolution, phones with very high resolution, "phablets" etc. It becomes decided that the goal will be to make a pixel perfect design (just like for the iPhone!) for the Android phone the designer has, and perhaps the other one the boss has, and then to just pretend that the other 99% of the Android market does not exist.
There is more Android work then experienced Android programmers, so some inexperienced kid right out of college is the programmer on the project, who is easily intimidated by the designer. They proceed this way until weeks and months go by and the CEO realizes the app looks like junk on tablets and most phones, and then blames the programmer for this situation.
Anyone thinking of stepping into a role as an Android programmer should get everyone on the same page about the UI goals before he agrees to work on the project. Especially between you and the designer and whoever your common management is, perhaps all the way to the top. Because the easy way is for the designer to do what he did for iPhone - 2 designs for the 2 phones he has access to, which are pixel perfect (which is completely pointless if it looks like crap on 99% of phones).
This situation arises again and again and again.
If there's any secondary thing, I guess it would be how far back you want to support Android in terms of versions. You really don't want to support something before v3.0 if you can avoid it.