2016-03-18 7 views
3

Dernièrement, nous avons acquis un nouveau Galaxy S6 avec Android 5.1.1 et nous avons quelques problèmes avec le nouveau gestionnaire de mémoire Samsung SPCM qui l'accompagne. Il ferme agressivement le service d'arrière-plan de notre application, qui, bien que défini sur START_STICKY, ne redémarre pas.Traiter avec Samsung SPCM tueur

De plus, le service ne prend pas plus de 5 Mo de RAM, mais nous obtenons toujours le score le plus bas de l'algorithme SPCM et nous choisissons de le tuer.

C'est notre 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 
    } 
} 

Et dans le manifeste:

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

Un journal de SPCM tuer nos services:

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} 

Même si les États log ActivityManager il est de réordonner un redémarrage pour notre service, il ne sera jamais réellement redémarré.

Nous avons vu les mêmes journaux SPCM concernant d'autres applications (Facebook, TrueCaller, etc.) mais leurs services réussissent à redémarrer.

Pour résumer, nos questions sont les suivantes:

  1. Comment éviter SPCM de cibler notre application en tant que paquet lowestscore?
  2. Si nous avons été ciblés, comment nous assurer que notre service sera redémarré avec succès après avoir été tué?
  3. D'autres idées qui peuvent nous aider?
+0

J'ai le même problème. Avez-vous résolu cela? – kakopappa

+0

Nous avons réussi à mais essayé de nombreuses choses que nous ne sommes pas complètement sûr de ce qui a aidé :) Parmi les choses étaient: Diminuer la consommation de la mémoire de notre application. Nous supposons que SPCM ne nous a plus ciblés. Je te souhaite bonne chance! – Nom1fan

Répondre

0

Assurez-vous que ActivityManager is not targeting your service too. AFAIK il n'y a pas d'autre moyen d'assurer la survie que d'avoir une notification persistante, c'est aussi ce que disent les développeurs de Samsung. En ce qui concerne Facebook et TrueCaller, je n'ai pas de réponses. Peut-être qu'ils utilisent d'autres processus connexes pour obtenir des services de sauvegarde. En ce qui concerne les appareils concernés, le premier que j'ai vu était un Galaxy Tab S SM-T805 avec 5.0.2. Un grand nombre de périphériques Samsung 5.1.1 ont aussi SPCM. Nous avons d'abord reproduit le problème sur un S6 et je peux confirmer qu'il est toujours présent sur 6.0.1. En ce qui concerne la documentation, this Samsung forums topic va aussi loin que possible.

pour les essais et les étapes de reproduction Je conseille à:

  1. Assurez-vous que l'appareil a en fait SPCM adb shell getprop | grep spcm.
  2. Débranchez-le de toute source d'alimentation.
  3. Installez Tinycore pour observer l'utilisation de la RAM (activer la notification persistante pour celle-ci). Chargez beaucoup d'applications gourmandes en RAM pour augmenter le score de vos services. Sinon, essayez le Developer Toolbelt, il devrait être plus rapide que de le remplir à la main, mais je ne l'ai pas testé.
  4. Eteignez l'écran et donnez 15 minutes à l'appareil.
  5. adb shell logcat -v threadtime | grep spcm pour confirmer que les processus ont été supprimés. Rincer et répéter jusqu'à ce que réussie.
0

Je vais essayer de vous aider à répondre à votre question 3:

Je suis face à la même question et la meilleure solution que j'ai trouvé est d'utiliser AlarmManager pour démarrer mon service. J'ai donc réglé AlarmManager toutes les 30 minutes et démarré mon service. S'il est toujours en cours d'exécution, onStartCommand sera appelé à nouveau, sinon le service sera recréé. J'ai fait quelques ajustements dans mon code pour traiter les nouveaux appels à onStartCommand toutes les 30 minutes et ça fonctionne comme je l'espérais. L'inconvénient est l'épuisement de la batterie, car mon service est toujours en cours d'exécution et Android ne passe jamais en mode veille (travaille encore sur elle). Une autre approche consiste à configurer votre service à l'avant-plan, mais dans mon cas ce n'est pas ce que je veux faire.

Vous pouvez essayer de désactiver SPCM, ouvrez votre build.prop et changer la ligne suivante (nécessite root):

sys.config.spcm_enable=true 

à:

sys.config.spcm_enable=false 

Jetez un oeil here et here.

Espérons que ça aide.