Hay muchos factores a considerar:.
audiencia
1. Objetivo
1.5 no importa mucho hoy, y no recomiendo que la gente lo dirija a menos que realmente lo necesite. La detección de la aplicación es 0.9% hoy para esos dispositivos, de acuerdo con current Market statistics.
Desde el punto de vista de la audiencia, 1.5 es irrelevante.
1.6 es alrededor del 1,4% en la actualidad, que es un poco más, pero sigue siendo una pista. Solo por este argumento, no es importante.
También hay un problema muy importante: la tecnología de su público objetivo. Estos son nichos de mercado. Por ejemplo, hay algunos dispositivos iDEN en 1.5, y el soporte de Cupcake es muy importante cuando se trata de esos usuarios.
No debe suponer que debido a que un dispositivo en EE. UU. Está actualizado con 2.1, está en otra parte. Motorola, por ejemplo, tiene una terrible historia de dispositivos de soporte en otros países. Ver, por ejemplo, la tendencia #MOTOFAIL.
También debería considerar el objetivo del país. La gente de allí, con menos dinero, es más propensa a tener dispositivos pre-Eclair en la actualidad y dispositivos pequeños eclair/froyo. Debes tener esto en cuenta y equilibrar tus necesidades de API. Pero no he encontrado que esto sea relevante todavía, hoy. Esto es muy importante en los países más pobres que todavía están inundados con 1.5 dispositivos, pero incluso eso está cambiando (nuevamente, experiencia personal).
Finalmente, existe el factor de rentabilidad pura. Desde mi experiencia personal, los usuarios con 1.5 y 1.6 tienen muchas menos probabilidades de pagar y soportar una aplicación. Tengo una aplicación en el modelo freemium. Tengo 4 veces (proporcionalmente, obviamente) más usuarios en la aplicación gratuita que en la aplicación de pago.
2. Funciones de la API y la facilidad de desarrollo
No recomiendo focalización 1.5 debido a sus peculiaridades de diseño. Si trabajaste lo suficiente con él, verías que hay imperfecciones con el diseño y la disponibilidad disponible. La primera aplicación foursquare (solo un ejemplo que estaba viendo hoy, en Google Code) tiene muchas líneas que solo tienen en cuenta esos problemas. En mi humilde opinión, no vale la pena.
Lo bueno de 1.6 es que se accede a muchas muy importantes bibliotecas, principalmente los fragmentos y los cargadores, los cuales fueron portados de nuevo a 1.6 y le hará la vida que mucho más fácil. No pierde mucho mientras sigue dando soporte a todos esos dispositivos heredados.
Esa es la razón principal por la que las personas están estableciendo 1.6 como API mínima hoy.
Siempre que mezcle necesidades, usted debe lea .
Y ahora los problemas menores. Si su proyecto es demasiado grande, es posible que desee preguntarse si vale la pena apuntar a un dispositivo sin la función app2sd que se introdujo en froyo/2.2/api-8. Sin embargo, siento que no es el caso. Y hay otros problemas menores que no puedo recordar ahora.
Sin embargo, 1.6 no es el santo graal. Si apunta a 1.6, encontrará pequeñas molestias. Solo para contar un pequeño ejemplo, no creo, digamos, onKeyLongPress() is available on pre-2.0 devices. Lo mismo con Service.onStartCommand y muchos indicadores de servicio (api 5 y superior).
Por ejemplo, me gusta confiar en START_FLAG_REDELIVERY o START_STICKY. Entonces, si bien puedes usar Loader en 1.6, me encuentro necesitando otras características para complementar las deficiencias de 1.6. Y la mayoría de estas características no están disponibles para 1.6 AFAIK.
Y ese es solo uno de los pequeños problemas. Están dispersos, lo que dificulta su realización.
Las mejores API le ofrecen menos tiempo de comercialización y una productividad más rápida.
3. El desarrollo de estrategias
En lo personal, me gustaría hacer el siguiente (en realidad estoy haciendo ahora): desarrollar un dispositivo de nivel inferior (1.6), y cada vez que sienta la necesidad de implemente algo que no está allí, cambie su objetivo a una API más alta para obtener su "sensación". Eso ayuda cuando ya sabes qué implementar.
Cuando no sabe qué implementar (en cuanto al código, por supuesto), seleccione la API más alta (generalmente 2.3) para poder navegar por las funciones de finalización de código. Sé que esto suena un poco como "ensayo y error", pero no sé si hay una forma más práctica de aprender esto.
4. La fragmentación
Como sé que esto va a generar los f-word comments, tener en cuenta que esto, al menos en mi opinión, no es mucho acerca de la fragmentación, pero mucho más sobre el aprendizaje de la API y conocer su objetivo y mercado. La fragmentación es secundaria a esta discusión, por lo que creo que es mejor evitar este acalorado debate.
Técnicamente, puede ver las diferencias en el sitio API Difference.
Sí, creo que es una muy buena visión general.
Apéndice: lo que he hecho hoy (editado)
En general, todo lo demás es igual y por una aplicación en general, me gustaría min a 7 API/Eclair. Sigue siendo el 97% de los dispositivos que se encuentran actualmente en el mercado, al mismo tiempo que le brinda características para aplicaciones ricas y facilidad de desarrollo, al mismo tiempo que lo hace más productivo con menos tiempo de lanzamiento al mercado y al mismo tiempo asegura cierta rentabilidad.
¿Obtienes puntos extra por el cierre de las preguntas como malo? Esta es una pregunta muy específica sobre las capacidades técnicas de la plataforma y no se trata de opinión. En resumen, si apuntas a Android 2.1, funcionará en una versión posterior. ¿Por qué es probable que provoque el debate? Para prueba de que no verá las respuestas a continuación. Sospecho que la mayoría de los nuevos desarrolladores de Android necesitarán responder a una versión de esta pregunta: no se trata de la cantidad de dispositivos o si debe apuntar a una plataforma x o y, pero funcionará en 3,4,5 si está construido para 2. – Chanoch