Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Boot complete broadcast procesado en serie en KITKAT 4.4.2 <ACTION_BOOT_COMPLETED> <ActivityManagerService.java>

Parece que hay un cambio muy importante en la forma en que se transmite ACTION_BOOT_COMPLETED en la última versión de android. En JB 4.3, la transmisión completa de arranque se procesó en paralelo. Donde como en KK 4.4.2 su ser procesado en serie. Esto está retrasando el inicio de servicios después de arrancar.

KITKAT 4.4.2

HABA DE JALEA 4,3

Debido a este cambio de Google, mi inicio de servicio se está retrasando después del inicio completo. Se puede observar que el dispositivo se vuelve lento y que el audio para tocar no se reproduce. Todo esto porque los servicios respectivos están comenzando tarde.

También, de los registros veo que el primer individuo a recibir ACTION_BOOT_COMPLETED después de su se envía, lo está recibiendo después de 16-19 segundos, donde como en JBP apenas toma 10 milisegundos para el primer individuo en la cola del receptor para conseguirlo .

¿Podría alguien que es consciente de este cambio explicar por qué se hizo esto. Sería una gran ayuda.

¡Muchas gracias!

  • Manejo de mapas de bits grandes
  • Rendimiento de Android xml vs java layouts
  • Alto uso de la CPU con el emulador de Android (qemu-system-i386.exe)
  • C + + pura aplicación para Android y su rendimiento
  • ¿La codificación dura de la cadena afecta el rendimiento?
  • Cómo obtener el tiempo de computación en NDK
  • ¿Por qué android: singleLine = "true" hace el desplazamiento ListView muy laggy?
  • Android drawBitmap rendimiento de lotes de mapas de bits?
  • 3 Solutions collect form web for “Boot complete broadcast procesado en serie en KITKAT 4.4.2 <ACTION_BOOT_COMPLETED> <ActivityManagerService.java>”

    El cambio fue hecho por @hackbod, tal vez ella puede arrojar luz sobre la razón.

    Su nota de checkin dice:

    Finalizar el problema # 10779747: Se ha producido un error en el almacenamiento …

    … mientras configura un nuevo usuario de la configuración.

    Ahora podemos retrasar las emisiones cuando hay suficientes servicios de fondo actualmente en marcha (todavía establecidos en 1 para los dispositivos de svelte, 3 para los dispositivos normales).

    Agregue un nuevo indicador de intención para no permitir que los receptores aborten las emisiones, que utilizo para solucionar un problema con la transmisión BOOT_COMPLETED inicial que no solicita datos pss en el momento adecuado – ahora se puede enviar como una transmisión ordenada sin la capacidad de los receptores Para cancelarlo.

    Registro de entrada

    Puede intentar modificar el código de seguimiento en frameworks \ base \ services \ java \ com \ android \ servidor \ am \ ActivityManagerService.java (línea 1974 alrededor):

    private ActivityManagerService() { ...... mBgBroadcastQueue = new BroadcastQueue(this, "background", BROADCAST_BG_TIMEOUT, true); ...... } 

    de:

     mBgBroadcastQueue = new BroadcastQueue(this, "background", BROADCAST_BG_TIMEOUT, true); 

    a:

     mBgBroadcastQueue = new BroadcastQueue(this, "background", BROADCAST_BG_TIMEOUT, false); 

    Otra solución es simplemente establecer la intención ACTION_BOOT_COMPLETED de ser "FLAG_RECEIVER_NO_ABORT" en finishBooting (), ActivityManagerService.java:

     final void finishBooting() { ... Intent intent = new Intent(Intent.ACTION_BOOT_COMPLETED, null); intent.putExtra(Intent.EXTRA_USER_HANDLE, userId); intent.addFlags(Intent.FLAG_RECEIVER_NO_ABORT); //add FLAG_RECEIVER_FOREGROUND to force the intent in foreground intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND); ...... } 

    Sí, conozco esta pregunta ahora. BOOT_COMPLETED ordered = true, muchos servicios de ejecución de demora por un largo tiempo. Si elimino todas las aplicaciones de GMS, estará bien. Debido a que muchas aplicaciones de GMS registran la transmisión BOOT_COMPLETED.

     public class BootReceiver extends BroadcastReceiver { @Override public void onReceive(Context arg0, Intent arg1) { // TODO Auto-generated method stub try { Thread.sleep(10000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } 

    Parece ser un error. Beacuse si escribo una aplicación de demostración para recibir el BOOT_COMPLETED como anteriormente, el problema incorrecto volverá a aparecer.

    He comprobado la modificación de @ hackbod. No tengo ninguna idea excepto para modificar ordenado de verdadero a falso. Esperando la respuesta @ hackbod!

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.