¿Por qué AOSP agrega nuevas API para admitir bibliotecas sin agregarlas al SDK?

He estado desarrollando para Android desde hace unos meses, y esta pregunta se plantea una y otra vez: ¿cuál es la motivación detrás de la adición de características completamente nuevas (API) para admitir bibliotecas sin que estén disponibles en el SDK estándar?

Ejemplo:

• ¿PreferenceFragment fue intencionalmente excluido del paquete de compatibilidad?
• ¿Por qué usar Fragmentos "regulares" cuando tienes el Paquete de Compatibilidad de Android?
• ¿Cómo puedo saber por qué el mercado de Android está filtrando mi aplicación en determinados teléfonos
• ¿Qué es LinearLayoutCompat en appCompat v7?
• ¿Cómo puedo usar el mismo conjunto de pantallas de preferencias para todas las versiones de Android de 2.X a 4.X?

FragmentTabHost API está disponible sólo a través de android.support.v4.app.FragmentTabHost . Está bien la mayoría del tiempo, pero si quieres usar fragmentos anidando y PreferenceFragment juntos, estás muerto en las aguas – anidar requiere que cambies a android.support.v4.app.Fragment (para soportar debajo de 4.2), pero no hay implementación de PreferenceFragment en esta lib de soporte. Como consecuencia, puede implementar soluciones personalizadas o utilizar bibliotecas de terceros que ya las han implementado (consulte esta pregunta )

Edit: como lo señaló @eugen en su respuesta, yo mismo referenciado FragmentTabHost de apoyo-v13, que apoya Fragmentos nativos. Sin embargo, esta información no cambia la pregunta general. De hecho, si hubiera usado esta API con fragmentos de anidación, mi aplicación no se ejecutaría en ~ 30% de los dispositivos de hoy (fragmentos nativos apoyo de anidación a partir de 4.2 en adelante).

Ejemplo:

Otro problema que he encontrado hoy (y desperdiciado demasiado tiempo en) es con ActionBarDrawerToggle disponible a través de android.support.v7.app.ActionBarDrawerToggle . Quise usar esta funcionalidad, por lo tanto agregué todo el com.android.support:appcompat-v7:21.0.+ a las dependencias del proyecto. Supongo que esto va a hacer, pero estaba equivocado – mi aplicación no compilar (falta de recursos referenciados por la biblioteca de soporte). Después de probar algunos trucos de la web, encontré esta pregunta que finalmente proporcionó la solución. En resumen: la biblioteca de soporte v7 tiene dependencia en SDK, por lo tanto tuve que definir compileSdkVersion 21 .

Consecuencias:

Ahora, me digo a mí mismo: FragmentTabHost no se han añadido a ninguna versión de SDK aún, lo que implica que incluso 4-5 años a partir de ahora los desarrolladores seguirán utilizando el soporte v4 lib para proporcionar esta funcionalidad (porque incluso si esta API se añade hoy , se necesitarán años para poder asumir con seguridad que todos los dispositivos de destino lo soportan de forma nativa), ¿verdad? El mismo argumento se aplica a android.support.v4.widget.DrawerLayout y otras API presentes sólo en bibliotecas de soporte.

Si los desarrolladores están obligados a usar bibliotecas de soporte durante años, esto también implica que están obligados a experimentar los problemas de inconsistencia / dependencia anteriores mucho después de que estos problemas ya podrían haber sido resueltos, ¿verdad?

Pregunta:

¿Por qué Google quiere mantener estas bibliotecas para siempre? ¿No será mejor para todos si todas las nuevas API se agregaran a SDK en paralelo con las librerías de compatibilidad, de modo que las bibliotecas de compatibilidad podrían envejecer y "retirarse" en algún momento?

Editar: después de la respuesta de @ eugen ahora estoy perplejo aún más – algunas API "evolucionan" con libs de soporte más recientes, pero no lo convierten en SDK principal (como FragmentTabHost, que evolucionó de soporte-v4 a support-v7). ¿Cuál es la razón para no agregarlos al SDK?

 compileSdkVersion 22 buildToolsVersion '22.0.1' targetSdkVersion 22 compile 'com.android.support:support-v4:22.0.0' compile 'com.android.support:appcompat-v7:22.0.0' // includes support-v4 compile 'com.android.support:support-v13:22.0.0' // includes support-v4