¿Por qué otro servicio encima de IMarketBillingService?

Google market_billing muestra , al igual que otros como este , se conecta al servicio remoto IMarketBillingService través de un contenedor de servicio local , BillingService .

Entiendo que los servicios tienen la ventaja de hacer las cosas en el fondo, pero no es el IMarketBillingService remoto suficiente?

¿Los códigos promocionales de compra en la aplicación rompen la verificación remota del servidor?
MService.consumePurchase (3, packageName, purchaseToken) devuelve siempre RESULT_DEVELOPER_ERROR = 5 - argumentos no válidos proporcionados a la API
En la facturación de aplicaciones v3 Artículos no consumibles de Android
En la aplicación de facturación, inventory.getPurchase es nulo en el dispositivo diferente que el pago se hizo
Consumir compras canceladas en la facturación en aplicaciones de Google Play

¿Cuál es la ventaja de agregar otra capa a esta cebolla?

¿Qué voy a perder si intento conectarme al IMarketBillingService remoto directamente desde mi actividad principal, en el hilo de la interfaz de usuario?

Si no es aconsejable conectarse al servicio de IMarketBillingService remoto directamente en el subproceso de interfaz de usuario, BillingService puede sustituirse el servicio de BillingService local por otro subproceso en la actividad principal?

El servicio de facturación local controla las devoluciones de llamada de IMarketBillingService cuando su actividad no se está ejecutando.

La referencia ( http://developer.android.com/reference/android/app/Activity.html ) dice:

"Si una actividad se detiene o se detiene, el sistema puede dejar caer la actividad de la memoria, ya sea pidiéndole que finalice, o simplemente matar su proceso.Cuando se muestra de nuevo para el usuario, debe ser reiniciado completamente y restaurado a su estado anterior . "

Si por ejemplo invoca una solicitud de facturación RESTORE_TRANSACTIONS, las respuestas del Servicio de Android Market pueden tardar algún tiempo en llegar. Al utilizar un servicio, usted sabe que siempre estará a su alrededor para manejar las respuestas, independientemente del ciclo de vida de la actividad.

Sólo por diversión, traté de escribir una pequeña aplicación de prueba y me sorprendió. Un subproceso en ejecución puede llamar a métodos en una actividad detenida o en pausa. El hilo también puede modificar su UI incluso cuando la actividad no está en primer plano. Ejecute la aplicación siguiente, presione la pantalla de inicio para detener la aplicación. Regresa después de 10 segundos y comprueba que TextView ha cambiado …

 package com.example.playground; import android.app.Activity; import android.os.Bundle; import android.util.Log; import android.widget.TextView; public class MyActivity extends Activity { private static String TAG = MyActivity.class.getName(); /** * Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); Thread t = new Thread(new Runnable() { public void run() { try { Thread.sleep(10000); someMethod(); } catch (InterruptedException e) { Log.e(TAG, e.getMessage(), e); } } }); t.start(); } private void someMethod() { Log.d(TAG, "Some method called"); TextView tv = (TextView) findViewById(R.id.textfield); tv.setText("Called later"); } }