Już nie chcę ActivityManager - nie jest to problem z usługą

Question

Pracuję nad aplikacją open source (droidwall fork) i utknąłem z jednym z problemów, gdy reguły iptables nie zostały poprawnie zastosowane po ponownym uruchomieniu systemu. działa doskonale na większości wersji Androida. Ale w niektórych szczególnych ROM (cm 10,1) daje następujące logcat

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

mój kod działa latków jak poniżej,

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);*/ 
    } 

można znaleźć moją klasę Api.java here.

Answer 1

12-26 08: 39: 27,116 I/ActivityManager (582): Nie chcą już dev.ukanth.ufirewall (PID 2297): pusty # 17

Ten dziennik oznacza, że ​​masz zasięg maksymalne dozwolone puste procesy. (16 jest max w danym przypadku)

Więcej o empty processes z Android doc:

Proces, który nie posiada żadnych aktywnych składników aplikacji. Jedynym powodem utrzymania tego rodzaju procesu przy życiu jest buforowanie, aby poprawić czas uruchamiania przy kolejnym uruchomieniu komponentu. System często zabija te procesy, aby zrównoważyć całkowite zasoby systemowe między pamięciami podręcznymi procesów i bazowymi pamięciami podręcznymi jądra.

Więc nie jestem pewien dziennik masz jest bezpośrednio związane problemu z regułami iptables.

Answer 2

Po zakończeniu metody onReceived() system zakłada, że ​​zakończyłeś pracę z BroadcastReceiver i ustawisz hostowany proces na najniższy priorytet. Wiemy również, że metoda tostera Handlarza handleMessage() nazywana jest asynchronicznie, która jest wywoływana po zakończeniu metody onReceived() i nie ma gwarancji, że proces jest nadal wykonywany, aby wykonać wywołanie zwrotne. W większości wersji systemu Android liczba procesów uruchomienie przy uruchomieniu systemu nie jest zbyt liczne i twój proces (z najniższym priorytetem) ma szansę pozostać przy życiu aż do wywołania metody wywołania zwrotnego handleMessaged(), ale z ROMS (CM 10.1) może być tak wiele procesów uruchomionych, że ten moment , system musi zabijać procesy o niższym priorytecie, aby uwolnić zasoby, aby procesy o wyższym priorytecie mogły działać poprawnie, a twój proces jest dobrym kandydatem do zabicia.

Proponuję uruchomić usługę do zrobienia tych asynchronicznych zadania, które sprawia, że ​​proces ma wyższy priorytet (priorytet usługi procesowego domyślnie lub użyć startForeground() sposób, aby uzyskać pierwszeństwo pierwszoplanowy-process)

Answer 3

Może ty użyć mHandler.post z pewnym opóźnieniem, aby przetestować swoją skrzynkę jak 20 sekund?