2016-03-18 6 views
3

Kürzlich haben wir ein neues Galaxy S6 mit Android 5.1.1 erworben und wir haben einige Probleme mit dem neuen Samsung SPCM Speichermanager, der damit einhergeht. Es schließt aggressiv den Hintergrunddienst unserer App, der zwar auf START_STICKY gesetzt ist, aber nicht neu gestartet wird.Umgang mit Samsung SPCM Killer

Zusätzlich benötigt der Dienst nicht mehr als 5MB RAM, aber irgendwie enden wir mit der niedrigsten Punktzahl des SPCM-Algorithmus und werden ausgewählt, um getötet zu werden.

Das ist unser Service:

Public class IncomingService extends Service { 

    @Override 
public int onStartCommand(Intent intent, int flags, int startId) { 
    super.onStartCommand(intent, flags, startId); 
    return START_STICKY; 

} 

@Override 
public void onCreate() { 
    if (mPhoneListener == null) { 
     mPhoneListener = new CallStateListener(); 
     TelephonyManager tm = (TelephonyManager) getApplicationContext().getSystemService(Context.TELEPHONY_SERVICE); 
     tm.listen(mPhoneListener, PhoneStateListener.LISTEN_CALL_STATE); 
} 

    /** 
* Listener for call states 
* Listens for different call states 
*/ 
private class CallStateListener extends PhoneStateListener { 

    @Override 
    public void onCallStateChanged(int state, String incomingNumber) { 
     // Doing something with incomingNumber 
    } 
} 

Und im Manifest:

<service 
     android:name="com.services.IncomingService" 
     android:enabled="true" 
     android:priority="999" > 
    </service>  

Ein Protokoll der SPCM unsere Dienstleistungen zu töten:

obwohl
Force stopping com.special.app appid=10499 user=0: SPCM kill lowestscore package! 
03-18 22:48:11.280 3562-3562/? I/ActivityManager: Killing 2279:com.special.app/u0a499 (adj 8): stop com.special.app cause SPCM kill lowestscore package! 
03-18 22:48:11.280 3562-3562/? W/ActivityManager: Scheduling restart of crashed service com.special.app/com.services.IncomingService in 1000ms 
03-18 22:48:11.280 3562-3562/? I/ActivityManager: Force stopping service ServiceRecord{27d2c408 u0 com.special.app/com.services.IncomingService} 

Auch das Activity Protokoll heißt es, Wenn Sie einen Neustart für unseren Dienst neu planen, wird er nie neu gestartet.

Wir haben die gleichen SPCM Logs in Bezug auf andere Apps (Facebook, TrueCaller, etc.) gesehen, aber ihre Dienste schaffen es irgendwie neu zu starten.

So zusammenzufassen, unsere Fragen sind:

  1. Wie SPCM zu verhindern, dass unsere App als lowestscore Paket-Targeting?
  2. Wenn wir anvisiert wurden, wie kann sichergestellt werden, dass unser Dienst nach dem Absturz erfolgreich neu gestartet wird?
  3. Irgendwelche anderen Ideen, die uns helfen können?
+0

Ich habe das gleiche Problem. Hast du das repariert? – kakopappa

+0

Wir haben es geschafft aber zu vielen Dingen versucht wir sind uns nicht ganz sicher was uns geholfen hat :) Zu den Dingen gehörten: Senken des Speicherverbrauchs unserer App. Wir gehen davon aus, dass SPCM uns nicht mehr angegriffen hat. Wünsch dir Glück! – Nom1fan

Antwort

0

Stellen Sie sicher, dass ActivityManager is not targeting your service too.

AFAIK gibt es keinen anderen Weg zu überleben als eine dauerhafte Benachrichtigung, das ist auch, was Samsung Entwickler Dokumente sagen. Was Facebook und TrueCaller betrifft, habe ich keine Antworten. Möglicherweise nutzen sie andere verwandte Prozesse, um Dienste wieder zu erhalten.

Wie für die betroffenen Geräte, die früheste ich sah, war ein Galaxy Tab S SM-T805 mit 5.0.2. Viele 5.1.1 Samsung Geräte haben auch SPCM. Wir haben das Problem zunächst auch auf einer S6 reproduziert und ich kann bestätigen, dass es auf 6.0.1 immer noch vorhanden ist.

Wie bei der Dokumentation geht this Samsung forums topic so weit wie möglich.

Für die Schritte Prüfung und Reproduktion ich raten:

  1. Stellen Sie sicher, dass das Gerät tatsächlich SPCM adb shell getprop | grep spcm.
  2. Trennen Sie den Stecker von allen Stromquellen.
  3. Installieren Sie Tinycore, um die RAM-Auslastung zu überwachen (aktivieren Sie eine permanente Benachrichtigung dafür).
  4. Laden Sie eine Menge RAM-hungrige Apps, um Ihre Dienste zu belasten. Alternativ versuchen Sie die Developer Toolbelt, sollte es schneller als das Füllen von Hand sein, aber ich habe es nicht getestet.
  5. Schalten Sie den Bildschirm aus und geben Sie dem Gerät 15 Minuten.
  6. adb shell logcat -v threadtime | grep spcm um zu bestätigen, dass Prozesse getötet wurden.
  7. Spülen und wiederholen bis erfolgreich.
0

Ich werde versuchen, Ihnen die Beantwortung Ihre dritte Frage zu helfen:

ich das gleiche Problem konfrontiert und die beste Abhilfe, die ich gefunden ist Alarmmanager zu verwenden, meinen Dienst zu starten. Also habe ich AlarmManager so eingestellt, dass er alle 30 Minuten läuft und meinen Dienst startet. Wenn es noch läuft, wird onStartCommand erneut aufgerufen, andernfalls wird der Dienst neu erstellt. Ich habe einige Änderungen in meinem Code vorgenommen, um alle 30 Minuten mit neuen Aufrufen von onStartCommand fertig zu werden, und es funktioniert so, wie ich es erwartet hatte. Der Nachteil ist der Batterieverbrauch, da mein Dienst immer läuft und Android niemals in den Schlafmodus geht (arbeitet immer noch daran). Ein anderer Ansatz besteht darin, Ihren Dienst so einzurichten, dass er im Vordergrund ausgeführt wird, aber in meinem Fall möchte ich das nicht tun.

können Sie versuchen, SPCM zu deaktivieren, öffnen Sie Ihre build.prop und ändern Sie die folgende Zeile (erfordert root):

sys.config.spcm_enable=true 

zu:

sys.config.spcm_enable=false 

here und here Werfen Sie einen Blick.

Ich hoffe, es hilft.