Mancato più tempo ActivityManager - Non è un problema di servizio

Question

Sto lavorando su un'applicazione open source (droidwall fork) e sono bloccato con uno dei problemi in cui le regole di iptables non venivano applicate correttamente quando il sistema si riavvia. funziona perfettamente sulla maggior parte delle versioni di Android. Ma su alcuni ROMS specifici (CM 10.1) dà il seguente logcat

12-26 08:39:27.116 I/ActivityManager(582): 
No longer want dev.ukanth.ufirewall (pid 2297): empty #17 

Il mio codice funziona quarantina come qui di seguito,

private Handler mHandler = new Handler(Looper.getMainLooper()); 
@Override 
public void onReceive(final Context context, final Intent intent) { 
    if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { 
     if (Api.isEnabled(context.getApplicationContext())) { 
      final Handler toaster = new Handler() { 
       public void handleMessage(Message msg) { 
        if (msg.arg1 != 0) Toast.makeText(context, msg.arg1, Toast.LENGTH_SHORT).show(); 
       } 
      }; 

      mHandler.post( 
      // Start a new thread to enable the firewall - this prevents ANR 
      new Runnable() { 
       @Override 
       public void run() { 
        if (!Api.applySavedIptablesRules(context.getApplicationContext(), false)) { 
         // Error enabling firewall on boot 
         final Message msg = new Message(); 
         msg.arg1 = R.string.toast_error_enabling; 
         toaster.sendMessage(msg); 
         Api.setEnabled(context.getApplicationContext(), false, false); 
        } 
       } 
      }); 
      // Start a new thread to enable the firewall - this prevents ANR 
     } 
     /*Intent i = new Intent(context, StartupService.class); 
     i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); 
     context.startService(i);*/ 
    } 

Potete trovare la mia classe Api.java here.

Answer 1

12-26 08: 39: 27,116 I/ActivityManager (582): non vogliono più dev.ukanth.ufirewall (pid 2297): vuoto # 17

Questo registro significa che hai portata i processi vuoti massimi consentiti. (16 è il massimo nel tuo caso)

più su empty processes da doc Android:

Un processo che non detiene componenti applicativi attivi. L'unica ragione per mantenere attivo questo tipo di processo è per scopi di memorizzazione nella cache, per migliorare il tempo di avvio la prossima volta che un componente deve essere eseguito in esso. Il sistema spesso uccide questi processi per bilanciare le risorse complessive del sistema tra le cache di processo e le cache del kernel sottostanti.

Quindi, non è sicuro il registro quello che hai è direttamente relative al tuo problema con le regole di iptables.

Answer 2

Dopo aver completato il metodo onReceived(), il sistema presuppone che il lavoro sia terminato con BroadcastReceiver e che il processo ospitato abbia la priorità più bassa. E sappiamo che il metodo handleMessage() di Handler del tostapane è chiamato in modo asincrono e viene chiamato dopo che il metodo onReceived() è terminato e non vi è alcuna garanzia che il processo sia ancora lì per eseguire il metodo di callback

Nella maggior parte delle versioni di Android, il numero di processi che l'avvio all'avvio del sistema non è così grande e il processo (con priorità più bassa) ha la possibilità di rimanere in vita fino a quando viene chiamato il metodo di richiamata handleMessaged(), ma con ROMS (CM 10.1), potrebbero esserci così tanti processi in esecuzione in quel momento , il sistema deve eliminare i processi con priorità più bassa per liberare le risorse in modo che i processi a priorità più elevata possano essere eseguiti correttamente e il processo è un buon candidato da uccidere.

Vi suggerisco di iniziare un servizio di fare i compiti asincroni, che rende il processo ha una maggiore priorità (priorità di servizio-processo di default oppure è possibile utilizzare startForeground() metodo per ottenere la priorità di primo piano-processo)

Answer 3

Forse si può usa mHandler.post con un certo ritardo per testare il tuo caso come 20 secondi?