What are common issues that small Android development teams experience?

I'm looking into learning more about the Android framework and I would also like开发者_JS百科 to understand what issues small development teams (< 10 people) for Android based phones are likely to run into (i.e. porting to other platforms, inadequate security testing, or just anything across the software development lifecycle that poses difficulties).

Any feedback or links to external resources considering this topic would be much appreciated.

Thanks

Your question is rather vague and open-ended with aspects that don't necessarily apply to Android but rather app development in general. However there is one tip I can give you that makes team development easier on Android: share a single debug keystore.

Before you can run an app on a phone, you have to sign that app with a keystore. When you're developing an Android app on your own in Eclipse, the plugin makes this part easy. It generates a debug keystore for you and signs it automatically when you build, so you never have to think about this part of the process. However, if you're collaborating with others a few issues come up if you're all using different keystores:

1. You can't upgrade each other's APKs on top of each other; you'll have to do a full uninstall/reinstall.

2. You will run into painful things with code that depends on keystore signatures (such as the Google Maps key, if you ever use that).

3. You'll have to sign your release code with a different keystore; you may get which apks are release and which are debug mixed up if you're signing with a boatload of different keystores.

Luckily there's an option to specify a debug keystore for Android to use, in Eclispe --> Preferences --> Android --> Build. Every team member should use the same keystore. The easiest way to make a debug keystore is to just copy one that Eclipse automatically creates. Alternatively you can make your own, using these guidelines.

This is common sense for some, but not for others. Make sure ALL team members document changes they made so you aren't wasting your time figuring it out yourself before you can advance further.

I had some team members who had trouble grasping that concept =p

Not only should you use revision control, but you should also use some sort of process that your team can agree on, such as SCRUM (http://en.wikipedia.org/wiki/Scrum_(development)). Set realistic goals, make sure your team members are on task, for heaven sakes COMMUNICATE, and have something set up to keep track of milestones, and bugs. Make sure everyone on your team knows what they are supposed to be doing, and when it's supposed to be done. If you get any flaky people on your team, boot them off because they will stall your project tremendously. I had this problem trying to work with another developer who didn't want to do anything, so I'm a one man team now.

In any development project with more than one developer, you need to use subversion. I've recently finished a project starting without it, writing over each others code just to find out that my code was erased two hours later. Our technical manager took three days learning subversion, installing it and teaching us, just to get the project moving again. Subversion is mandatory to any development project in my view.

Ref: http://en.wikipedia.org/wiki/Subversion