Comment simuler Android en tuant mon processus

Android tuera un processus s'il est en arrière-plan et le système d'exploitation décide qu'il a besoin des ressources (RAM, CPU, etc.). Je dois être capable de simuler ce comportement pendant les tests afin de pouvoir m'assurer que mon application se comporte correctement. Je veux pouvoir le faire de manière automatisée afin de pouvoir tester si l'application se comporte correctement chaque fois que cela se produit, ce qui signifie que je devrai tester cela dans chaque activité, etc.

Je sais comment tuer mon processus. Ce n'est pas le problème. Le problème est que lorsque je tue mon processus ( en utilisant DDMS, adb shell kill, Process.killProcess(), etc.) Android ne redémarre pas de la même façon qu'il serait si le système d' exploitation Android avait tué lui - même.

Si le système d'exploitation Android tue le processus (en raison des besoins en ressources), lorsque l'utilisateur revient à l'application, Android recrée le processus, puis recrée l' activité principale sur la pile d'activités (appel onCreate()).

D'un autre côté, si je tue le processus, Android suppose que l'activité en haut de la pile d'activités s'est mal comportée , donc il recrée automatiquement le processus, puis supprime l'activité supérieure de la pile d'activités et recrée l'activité qui se trouvait en dessous l'activité principale (appelant onCreate () `). Ce n'est pas le comportement que je souhaite. Je veux le même comportement que lorsque Android tue le processus.

Juste pour expliquer en images, si ma pile d'activités ressemble à ceci:

    ActivityA -> ActivityB -> ActivityC -> ActivityD

Si Android arrête le processus et que l'utilisateur retourne à l'application, Android recrée le processus et crée ActivityD.

Si je tue le processus, Android recrée le processus et crée ActivityC.

La meilleure façon de tester cela pour moi était de faire ceci:

• Ouvrez ActivityD dans votre application
• Appuyez sur le bouton Accueil
• Appuyez sur Terminate Applicationdans la fenêtre Logcat dans Android Studio (cela tuera le processus de l'application, assurez-vous de sélectionner votre appareil et de traiter dans les listes déroulantes Logcat en haut)
• Revenez à l'application avec un appui long sur Accueil ou des applications ouvertes (dépend de l'appareil)
• L'application démarrera dans ActivityD recréé (ActivityA, ActivityB, ActivityC sont morts et seront recréés lorsque vous y reviendrez)

Sur certains appareils, vous pouvez également revenir à l'application (ActivityD) avec Applications -> Icône de votre lanceur, mais sur d'autres appareils, il démarrera à la place ActivityA.

Voici ce que disent les documents Android à ce sujet:

Normalement, le système efface une tâche (supprime toutes les activités de la pile au-dessus de l'activité racine) dans certaines situations lorsque l'utilisateur sélectionne à nouveau cette tâche à partir de l'écran d'accueil. En règle générale, cela est fait si l'utilisateur n'a pas visité la tâche pendant un certain temps, par exemple 30 minutes.

Cela semble fonctionner pour moi:

adb shell am kill <package_name>

Ceci est différent de celui adb shell killmentionné par l'OP.

Notez que l'aide de la am killcommande dit:

am kill: Kill all processes associated with <PACKAGE>.  Only kills.
  processes that are safe to kill -- that is, will not impact the user
  experience.

Donc, cela ne tuera pas le processus s'il est au premier plan. Cela semble fonctionner comme l'OP le souhaitait en ce sens que si je quitte mon application, l'exécuter adb shell am kill <package_name>tuera l'application (je l'ai confirmé en utilisant pssur l'appareil). Ensuite, si je retourne à l'application, je suis de retour dans l'activité dans laquelle j'étais auparavant - c'est-à-dire dans l'exemple de l'OP, le processus est recréé et crée ActivityD (plutôt qu'ActivityC comme la plupart des autres méthodes de mise à mort semblent se déclencher).

Désolé, j'ai quelques années de retard pour l'OP, mais j'espère que d'autres trouveront cela utile.

Une autre méthode, probablement scriptable car elle ne nécessite pas de DDMS:

Configuration unique: accédez aux Options du développeur, sélectionnez Paramètre de limite de processus d'arrière-plan, modifiez la valeur de «Limite standard» à «Aucun processus d'arrière-plan».

Lorsque vous devez redémarrer le processus, appuyez sur le bouton d'accueil. Le processus sera tué (vous pouvez vérifier dans logcat / Android Monitor en studio - le processus sera marqué [DEAD]). Revenez ensuite à l'application à l'aide du sélecteur de tâches.

Cette question est ancienne mais, il existe une réponse à cette question qui ne nécessite pas adb, Android Studio, etc. La seule exigence est l'API 23 ou plus récente.

Pour simuler le redémarrage de l'application par système d'exploitation, accédez aux paramètres de l'application pendant que votre application est en cours d'exécution, désactivez (vous pouvez ensuite activer) une autorisation et renvoyez l'application à partir des applications récentes. Lorsque l'autorisation est désactivée, le système d'exploitation tue l'application mais conserve les états d'instance enregistrés. Lorsque l'utilisateur renvoie l'application, l'application et la dernière activité (avec l'état enregistré) sont recréées.

La méthode «Aucun processus d'arrière-plan» provoque parfois le même comportement, mais pas toujours. Par exemple, si l'application exécute un service d'arrière-plan, "Aucun processus d'arrière-plan" ne fait rien. Mais l'application peut être tuée par le système, y compris ses services. La méthode d'autorisation fonctionne même si l'application dispose d'un service.

Exemple:

Notre application a deux activités. ActivityA est l'activité principale qui est lancée à partir du lanceur. ActivityB est démarré à partir de ActivityA. Je montrerai seulement les méthodes onCreate, onStart, onStop, onDestroy. Android appelle onSaveInstanceState toujours avant d'appeler onStop, car une activité qui est à l'état d'arrêt peut être tuée par le système. [ https://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle]

Méthode d'autorisation:

<start app from launcher first time>
Application onCreate
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart
<open ActivityB>
ActivityB onCreate WITHOUT savedInstance
ActivityB onStart
ActivityA onStop (the order is like this, it is stopped after new one is started)
<go settings>
ActivityB onStop
<disable a permission>
//Application is killed, but onDestroy methods are not called.
//Android does not call onDestroy methods if app will be killed.
<return app by recent apps>
Application onCreate (this is the important part. All static variables are reset.)
ActivityB onCreate WITH savedInstance (user does not notice activity is recreated)
//Note that ActivityA is not created yet, do not try to access it.
ActivityB onStart
<return ActivityA by back>
ActivityA onCreate WITH savedInstance (user does not notice activity is recreated)
ActivityA onStart
ActivityB onStop
ActivityB onDestroy
<press back again, return launcher>
ActivityA onStop
ActivityA onDestroy
<open app again>
//does not call Application onCreate, app was not killed
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart

Je veux comparer d'autres méthodes qui sont mentionnées sur les autres réponses.

Ne pas conserver les activités: cela ne tue pas l'application.

<start app from launcher first time>
Application onCreate
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart
<open ActivityB>
ActivityB onCreate WITHOUT savedInstance
ActivityB onStart
ActivityA onStop
ActivityA onDestroy (do not keep)
<return launcher by home button>
ActivityB onStop
ActivityB onDestroy (do not keep) 
<retun app from recent apps>
// NO Application onCreate
ActivityB onCreate WITH savedInstance (user does not notice activity recreated)
ActivityB onStart
<return ActivityA by back>
ActivityA onCreate WITH savedInstance (user does not notice activity recreated)
ActivityA onStart
ActivityB onStop
ActivityB onDestroy
<press back again, return launcher>
ActivityA onStop
ActivityA onDestroy
<open app again>
//does not call Application onCreate, app was not killed
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart

Méthode d'arrêt forcé: ne stocke pas les états d'instance enregistrés

<start app from launcher first time>
Application onCreate
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart
<open ActivityB>
ActivityB onCreate WITHOUT savedInstance
ActivityB onStart
ActivityA onStop
<go settings>
ActivityB onStop
<force stop, return app from recent apps>
Application onCreate
ActivityA onCreate WITHOUT savedInstance 
//This is important part, app is destroyed by user.
//Root activity of the task is started, not the top activity.
//Also there is no savedInstance.

Je suis très en retard à la fête et plusieurs avant moi ont donné la même réponse correcte mais pour simplifier pour celui qui vient après moi, appuyez simplement sur le bouton d'accueil et exécutez cette commande:

adb shell ps | grep <package name> | awk '{print $2}' | xargs adb shell run-as <package name again> kill

L'application ne perdra pas son état et, d'après ma propre expérience, cela fonctionne de la même manière que le système d'exploitation a tué l'application en arrière-plan. Cela ne fonctionne que pour les applications créées par débogage

Voici comment procéder dans Android Studio.

1. Connectez votre appareil en mode débogage à votre ordinateur.
2. Ouvrez l'application sur votre appareil et accédez à l'activité pour laquelle vous souhaitez tester le "Revenir d'entre les morts".
3. Appuyez sur le bouton Accueil de votre appareil.
4. Dans Android Studio, accédez à Moniteur Android -> Moniteurs et appuyez sur l'icône Terminer l'application.
5. Maintenant, vous pouvez revenir à votre application via les applications récentes ou en cliquant sur l'icône du lanceur, le comportement a été le même dans mes tests.

Mettez l'application en arrière-plan avec le bouton HOME

Sélectionnez votre processus en mode "Logcat" dans Android Studio, puis cliquez sur Terminer l'application dans le coin inférieur gauche

Maintenant, lancez votre application à partir du lanceur sur un appareil Android

EDIT: Selon Internet, ce qui suit fonctionne également:

 adb shell am kill [my-package-name]

EDIT from the future: quelque chose à noter, il y a eu un changement dans Android Studio 4.0, si vous utilisez à Runpartir d'AS, alors Terminateémettra un fichier Force Stop.

Cependant, si vous lancez à partir du lanceur par la suite, et ALORS vous essayez de le simuler de cette façon, vous obtiendrez les résultats que vous souhaitez (comportement de mémoire faible).

Vous pouvez effectuer les étapes suivantes pour reproduire le comportement recherché:

1. Ouvrez votre application, accédez à l'activité principale
2. Utilisez le panneau de notification pour accéder à une autre application en plein écran (par exemple, aux paramètres système - dans le coin supérieur droit)
3. Tuez votre processus de candidature
4. Appuyez sur le bouton retour

Dans les options du développeur sous Paramètres, sélectionnez «Ne pas conserver les activités», ce qui détruira les activités dès que vous vous en éloignerez.

Remarque: conformément à un commentaire utile ci-dessous, ne l'utilisez que si vous ne vous souciez pas de l'effacement des valeurs statiques.

Appuyez sur le bouton Accueil et placez d'abord l'application en arrière-plan. Arrêtez ou arrêtez ensuite le processus à partir de DDMS ou ADB.

Vous pouvez également vous connecter à votre appareil / émulateur à partir du terminal avec adb shell, puis obtenir le PID de votre processus avec ps | grep <your_package_nameet l'exécuter kill -9 <pid>. Ensuite, ouvrez votre application réduite à partir du sélecteur d'applications récentes et elle redémarrera la dernière activité

La racine de votre problème semble être que vous Activityêtes au premier plan lorsque vous tuez le processus.

Vous pouvez observer cela en appuyant sur stop dans DDMS quand Activityest visible (se produit exactement ce que vous décrivez) et en comparant cela à appuyer sur stop après la maison et à revenir plus tard à l'application.

Assurez-vous simplement de le faire moveTaskToBack(true)dans vos tests.

Je ne suis pas sûr que ce soit la réponse que vous recherchez, c'est plutôt une réflexion logique.

Je ne pense pas que vous puissiez vraiment faire un test entièrement automatisé, le seul moyen de le simuler, ce sera de le recréer, AKA a tellement d'activités qu'Android va tuer votre application.

Donc, mon idée ou suggestion est de créer une autre petite application, qui continue de faire apparaître de nouvelles activités, jusqu'à ce qu'Android manque de mémoire et commence à tuer le processus en arrière-plan.

Quelque chose parmi la ligne:

Démarrer l'activité i -> Vérifier le processus en cours si l'application est dans la liste, incrémenter i et redémarrer la boucle sans fermer l'activité actuelle, sinon -> diminuer i et fermer l'activité actuelle, revenir à la précédente et revérifier ...

Lorsque le processus de candidature meurt, Android parcourt les enregistrements d'activités (les entrées représentent des activités dans la pile d'historique) et décide lesquelles conserver dans l'historique et celles à supprimer.

L'un des points clés ici est le ActivityRecordchamp appelé haveState, que les ingénieurs d'Android Framework décrivent comme "avons-nous obtenu le dernier état d'activité?".

Par défaut, Android considère que l'activité a un état. L'activité devient sans état lorsque l'application signale au service du gestionnaire de tâches d'activité que l'activité a repris et cela est valide jusqu'à ce que l'application notifie à l' infrastructure que l'activité est entrée dans l'état Arrêté. En termes simples, la haveStatevaleur est falseentre l'activité onResume()est appelée et onStop()ou onSaveInstanceState()est appelée, selon la version cible de l'application.

Si je tue le processus, Android recrée le processus et crée ActivityC.

Dans ce cas, ActivityD n'a pas d' android:stateNotNeeded="true"attribut dans le manifeste de l'application et il est actuellement en cours d'exécution au premier plan, donc Android le supprime de l'historique car le système n'a pas obtenu son dernier état.

Comment simuler Android en tuant mon processus

Comme cela a été mentionné à plusieurs reprises, vous pouvez simplement déplacer l'application en arrière-plan, de sorte que l'activité principale de la pile arrière d'activité enregistre son état, et après cela, vous pouvez tuer le processus d'application via Android Debug Bridge, Android Studio ou en utilisant le Propriété Limite des processus d'arrière-plan dans les options du développeur. Après cela, votre activité récente sera recréée avec succès.

Malgré cela, il existe également un autre moyen simple de tester le scénario de décès du processus de candidature. Sachant tout ce qui est décrit ci-dessus et le fait que si vous démarrez un nouvel ActivityE à partir de ActivityD en cours d'exécution, le onStop()rappel ActivityD n'est appelé qu'après la onResume()méthode ActivityE , vous pouvez effectuer l'astuce suivante.

class TerminatorActivity : Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val isPrePie = applicationInfo.targetSdkVersion < Build.VERSION_CODES.P
        val callbacks = TerminatorLifecycleCallbacks(isPrePie)
        (applicationContext as Application).registerActivityLifecycleCallbacks(callbacks)
    }

    private class TerminatorLifecycleCallbacks(
        // Before P onSaveInstanceState() was called before onStop(), starting with P it's
        // called after
        // Used to schedule the death as app reports server that activity has stopped
        // after the latest of these was invoked
        private val isPrePie: Boolean
    ) : ActivityLifecycleCallbacksDefault {

        private val handler = Handler(Looper.getMainLooper())

        override fun onActivityPostStopped(activity: Activity) {
            if (isPrePie) {
                terminate()
            }
        }

        override fun onActivityPostSaveInstanceState(activity: Activity, outState: Bundle) {
            if (!isPrePie) {
                terminate()
            }
        }

        fun terminate() {
            handler.postDelayed(
                {
                    Process.killProcess(Process.myPid()) // This is the end... 
                },
                LAST_MILLIS
            )
        }

        companion object {
            // Let's wait for a while, so app can report and server can handle the update
            const val LAST_MILLIS = 100L
        }

    }

    private interface ActivityLifecycleCallbacksDefault : Application.ActivityLifecycleCallbacks {
        override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {}
        override fun onActivityStarted(activity: Activity) {}
        override fun onActivityResumed(activity: Activity) {}
        override fun onActivityPaused(activity: Activity) {}
        override fun onActivityStopped(activity: Activity) {}
        override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle) {}
        override fun onActivityDestroyed(activity: Activity) {}
    }
}

Ensuite, commencez simplement TerminatorActivitylorsque vous souhaitez supprimer l'application.

À la fin, il existe un outil léger qui simplifie les tests de la mort de votre processus d'application, appelé Venom .