Non desidera più ActivityManager – Non un problema di servizio

Sto lavorando su un'applicazione open source (droidwall fork) e sono bloccato con una delle questioni che le regole iptables non sono state applicate correttamente quando il sistema si riavvia. funziona perfettamente sulla maggior parte delle versioni Android. Ma su alcune specifiche ROM (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 come qualcosa di sotto,

  • Come get l'istruzione di guida di Google utilizzando google map api su android?
  • Android - EditText fornisce l'exception di IndexOutOfBounds durante l'utilizzo di textAllCaps
  • button in android di listview espandibile
  • Come fare la linea con angoli arrotondati (lisci) con AndroidPlot
  • Come aggiungere SwipeRefreshLayout a WebView
  • "Data senza paragone" utilizzando SimpleDateFormatter con l'esempio di codice API
  •  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);*/ } 

    Qui puoi trovare la mia class Api.java.

  • Android Asynctask per elaborare frame video in diretta
  • come scoprire o recuperare tutta l'elenco di amici di facebook con il loro profilo pic, nome e id
  • Esegui emulatore di studio Android sul processre AMD
  • Come aggiungere la barra di ricerca con il text modificato nella barra degli strumenti
  • Firebase sovrascrive Signin con Google Account
  • NoClassDefFoundError usando Jackson 2.2.x su Android con Gradle
  • 3 Solutions collect form web for “Non desidera più ActivityManager – Non un problema di servizio”

    12-26 08: 39: 27.116 I / ActivityManager (582): Non più desidera dev.ukanth.ufirewall (pid 2297): vuoto # 17

    Questo log significa che hai raggiunto i processi vuoti consentiti. (16 è il massimo nel tuo caso)

    Maggiori informazioni sui processi vuoti da android doc:

    Un process che non contiene componenti di applicazione attivi. L'unico motivo per mantenere vivo questo tipo di process è per scopi di memorizzazione nella cache, per migliorare il tempo di avvio nella prossima volta che un componente deve eseguire in esso. Il sistema spesso uccide questi processi per equilibrare le risorse complessive di sistema tra le cache dei processi e le cache di kernel sottostanti.

    Quindi, non sappiate che il tuo log è direttamente correlato al tuo problema con le regole iptables.

    Dopo che il metodo onReceived() terminato, il sistema presume che sia terminato con BroadcastReceiver e che il process ospitato sia impostato come priorità minima. E sappiamo che il metodo handleMessage() di Handler del tostapane viene chiamato asincrono che viene chiamato dopo che il metodo onReceived() è terminato e non vi è garanzia che il process sia ancora presente per eseguire il metodo di callback

    Nella maggior parte delle versioni Android, il numero di processi in esecuzione all'avvio del sistema non è tante e il process (con priorità minima) ha la possibilità di rimanere in vita fino a quando non viene chiamato il metodo callbackMessaged handleMessaged() , ma con ROM (CM 10.1 ), ci possono essere tanti processi in esecuzione in quel momento, il sistema deve uccidere processi di priorità inferiori per liberare le risorse in modo che i processi di priorità più elevati possano funzionare correttamente e il process è un buon candidato da uccidere.

    Vi suggerisco di avviare un servizio per eseguire quelle attività asincrone che rendono il process più elevato (priorità del process di servizio per impostazione predefinita oppure è ansible utilizzare il metodo startForeground() per get la priorità del process in primo piano)

    Forse è ansible utilizzare mHandler.post con qualche ritardo per testare il tuo caso come 20 secondi?

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.