L'application redémarre plutôt qu'elle ne reprend

J'espère que quelqu'un pourra m'aider à trouver, sinon une solution, au moins une explication d'un comportement.

Le problème:

Sur certains appareils, le fait d'appuyer sur l'icône du lanceur entraîne la reprise de la tâche en cours, sur d'autres, le déclenchement de l'intention de lancement initial (redémarrage effectif de l'application). Pourquoi cela arrive-t-il?

Le détail:

Lorsque vous appuyez sur l '"icône du lanceur", l'application démarre normalement - c'est-à-dire, je suppose, qu'une intention est lancée avec le nom de votre premier Activityavec l'action android.intent.action.MAINet la catégorie android.intent.category.LAUNCHER. Mais cela ne peut pas toujours être le cas:

Sur la majorité des appareils, si vous appuyez sur l'icône du lanceur après que l'application est déjà en cours d'exécution, l'activité en cours d'exécution dans ce processus est reprise ( PAS l'initiale Activity). Il reprend de la même manière que si vous l'aviez sélectionné dans les "Tâches récentes" du menu OS. C'est le comportement que je souhaite sur tous les appareils.

Cependant, sur certains autres appareils sélectionnés, un comportement différent se produit:

• Sur le Motorola Xoom, lorsque vous appuyez sur l'icône du lanceur, l'application démarre toujours le lancement initial, Activityindépendamment de ce qui est en cours d'exécution. Je suppose que les icônes du lanceur démarrent toujours l'intention "LAUNCHER".

• Sur le Samsung Tab 2, lorsque vous appuyez sur l'icône du lanceur, si vous venez d'installer l'application, elle lancera toujours la version initiale Activity(identique à Xoom) - cependant, après avoir redémarré l'appareil après l'installation, l'icône du lanceur sera à la place reprendre l'application. Je suppose que ces appareils ajoutent des "applications installées" dans une table de recherche au démarrage de l'appareil qui permettent aux icônes du lanceur de reprendre correctement les tâches en cours d'exécution?

J'ai lu de nombreuses réponses qui semblent similaires à mon problème, mais simplement ajouter android:alwaysRetainTaskState="true"ou utiliser launchMode="singleTop"le Activityne sont pas la réponse.

Éditer:

Après le lancement le plus récent de cette application, nous constatons que ce problème a commencé à se produire sur tous les appareils après le premier redémarrage. Ce qui me semble fou, mais en regardant à travers le processus de redémarrage, je ne peux pas vraiment trouver ce qui ne va pas.

Le comportement que vous rencontrez est dû à un problème qui existe dans certains lanceurs Android depuis l'API 1. Vous pouvez trouver des détails sur le bogue ainsi que des solutions possibles ici: https://code.google.com/p/android/issues/ détail? id = 2373 .

C'est un problème relativement courant sur les appareils Samsung ainsi que sur d'autres fabricants qui utilisent un lanceur / skin personnalisé. Je n'ai pas vu le problème se produire sur un lanceur Android d'origine.

Fondamentalement, l'application ne redémarre pas complètement, mais votre activité de lancement est en cours de démarrage et ajoutée en haut de la pile d'activités lorsque l'application est reprise par le lanceur. Vous pouvez confirmer que c'est le cas en cliquant sur le bouton de retour lorsque vous reprenez l'application et que l'activité de lancement s'affiche. Vous devriez ensuite être amené à l'activité que vous vous attendiez à voir lorsque vous avez repris l'application.

La solution de contournement que j'ai choisi d'implémenter pour résoudre ce problème consiste à vérifier la catégorie Intent.CATEGORY_LAUNCHER et l'action Intent.ACTION_MAIN dans l'intention qui démarre l'activité initiale. Si ces deux indicateurs sont présents et que l'activité n'est pas à la racine de la tâche (ce qui signifie que l'application était déjà en cours d'exécution), j'appelle finish () sur l'activité initiale. Cette solution exacte peut ne pas fonctionner pour vous, mais quelque chose de similaire devrait.

Voici ce que je fais dans onCreate () de l'activité initiale / de lancement:

    if (!isTaskRoot()
            && getIntent().hasCategory(Intent.CATEGORY_LAUNCHER)
            && getIntent().getAction() != null
            && getIntent().getAction().equals(Intent.ACTION_MAIN)) {

        finish();
        return;
    }

Cette question est toujours d'actualité en 2016. Aujourd'hui, un testeur QA a signalé qu'une de mes applications redémarrait plutôt que de reprendre à partir du lanceur de stock dans Android M.

En réalité, le système ajoutait l'activité lancée à la pile de tâches actuelle , mais il semblait à l'utilisateur que si un redémarrage s'était produit et qu'il avait perdu son travail. La séquence était:

1. Télécharger depuis Play Store (ou apk sideload)
2. Lancer l'application à partir de la boîte de dialogue Play Store: l'activité A apparaît [pile de tâches: A]
3. Accédez à l'activité B [pile de tâches: A -> B]
4. Appuyez sur le bouton «Accueil»
5. Lancer l'application depuis le tiroir des applications: l'activité A apparaît! [pile de tâches: A -> B -> A] (l'utilisateur peut appuyer sur le bouton «Retour» pour accéder à l'activité «B» à partir d'ici)

Remarque: ce problème ne se manifeste pas pour les APK de débogage déployés via ADB, uniquement dans les APK téléchargés depuis le Play Store ou chargés latéralement. Dans ces derniers cas, l'intention de lancement de l'étape 5 contenait l'indicateurIntent.FLAG_ACTIVITY_BROUGHT_TO_FRONT , mais pas dans les cas de débogage. Le problème disparaît une fois que l'application a été démarrée à froid à partir du lanceur. Je soupçonne que la tâche est semée avec une intention mal formée (plus précisément, non standard) qui empêche le comportement de lancement correct jusqu'à ce que la tâche soit entièrement effacée.

J'ai essayé divers modes de lancement d'activité , mais ces paramètres s'écartent trop du comportement standard auquel l'utilisateur s'attendrait: reprise de la tâche à l'activité B. Voir la définition suivante du comportement attendu dans le guide des tâches et de la pile arrière , au bas de la page sous 'Démarrage d'une tâche':

Un filtre d'intention de ce type entraîne l'affichage d'une icône et d'une étiquette pour l'activité dans le lanceur d'applications, offrant aux utilisateurs un moyen de lancer l'activité et de revenir à la tâche qu'elle crée à tout moment après son lancement.

J'ai trouvé cette réponse pertinente et j'ai inséré ce qui suit dans la méthode «onCreate» de mon activité racine (A) afin qu'elle reprenne correctement lorsque l'utilisateur ouvre l'application.

                    /**
     * Ensure the application resumes whatever task the user was performing the last time
     * they opened the app from the launcher. It would be preferable to configure this
     * behavior in  AndroidMananifest.xml activity settings, but those settings cause drastic
     * undesirable changes to the way the app opens: singleTask closes ALL other activities
     * in the task every time and alwaysRetainTaskState doesn't cover this case, incredibly.
     *
     * The problem happens when the user first installs and opens the app from
     * the play store or sideloaded apk (not via ADB). On this first run, if the user opens
     * activity B from activity A, presses 'home' and then navigates back to the app via the
     * launcher, they'd expect to see activity B. Instead they're shown activity A.
     *
     * The best solution is to close this activity if it isn't the task root.
     *
     */

    if (!isTaskRoot()) {
        finish();
        return;
    }

MISE À JOUR: a déplacé cette solution des indicateurs d'intention d'analyse pour demander si l'activité est directement à la racine de la tâche. Les indicateurs d'intention sont difficiles à prévoir et à tester avec toutes les différentes façons d'ouvrir une activité PRINCIPALE (lancement à partir de la maison, lancement à partir du bouton 'haut', lancement à partir de Play Store, etc.)

Ah! (tldr; voir les déclarations en gras en bas)

J'ai trouvé le problème ... je pense.

Donc, je vais commencer par une supposition. Lorsque vous appuyez sur le lanceur, il démarre la valeur par défaut Activityou, si un Taskdémarré par un lancement précédent est ouvert, il le place au premier plan. Autrement dit - si, à un stade quelconque de votre navigation, vous créez un nouveau Tasket finishl'ancien, le lanceur ne reprendra plus votre application.

Si cette supposition est vraie, je suis presque sûr que cela devrait être un bug, étant donné que chacun Taskest dans le même processus et est tout aussi valide un candidat de reprise que le premier créé?

Mon problème a ensuite été résolu en supprimant ces indicateurs de quelques-uns Intents:

i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK );

Bien qu'il soit assez évident que cela FLAG_ACTIVITY_NEW_TASKcrée un nouveau Task, je n'ai pas apprécié que la supposition ci-dessus soit en vigueur. J'ai considéré cela comme un coupable et l'ai retiré pour le tester et j'avais toujours un problème, donc je l'ai rejeté. Cependant, j'avais toujours les conditions ci-dessous:

i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP)

Mon écran de démarrage commençait le "principal" Activitydans mon application en utilisant le drapeau ci-dessus. Après tout, si j'avais "redémarré" mon application et que celle-ci Activityfonctionnait toujours, je préférerais de loin conserver ses informations d'état.

Vous remarquerez dans la documentation qu'il ne fait aucune mention du démarrage d'un nouveau Task:

S'il est défini et que l'activité en cours de lancement est déjà en cours d'exécution dans la tâche en cours, alors au lieu de lancer une nouvelle instance de cette activité, toutes les autres activités au-dessus seront fermées et cette intention sera livrée au (maintenant sur haut) ancienne activité en tant que nouvelle intention.

Par exemple, considérons une tâche composée des activités: A, B, C, D. Si D appelle startActivity () avec une intention qui se résout en composante de l'activité B, alors C et D seront terminés et B recevra l'intention donnée , ce qui donne maintenant la pile: A, B.

L'instance en cours d'exécution de l'activité B dans l'exemple ci-dessus recevra la nouvelle intention que vous démarrez ici dans sa méthode onNewIntent (), ou sera elle-même terminée et redémarrée avec la nouvelle intention. S'il a déclaré que son mode de lancement était "multiple" (par défaut) et que vous n'avez pas défini FLAG_ACTIVITY_SINGLE_TOP dans la même intention, alors il sera terminé et recréé; pour tous les autres modes de lancement ou si FLAG_ACTIVITY_SINGLE_TOP est défini, cette intention sera livrée à onNewIntent () de l'instance actuelle.

Ce mode de lancement peut également être utilisé à bon escient en conjonction avec FLAG_ACTIVITY_NEW_TASK: s'il est utilisé pour démarrer l'activité racine d'une tâche, il mettra au premier plan toute instance en cours d'exécution de cette tâche, puis l'effacera à son état racine. Cela est particulièrement utile, par exemple, lors du lancement d'une activité à partir du gestionnaire de notifications.

J'ai donc eu la situation décrite ci-dessous:

• Alancé Bavec FLAG_ACTIVITY_CLEAR_TOP, Afinitions.
• Bsouhaite redémarrer un service envoie donc l'utilisateur Aauquel a la logique de redémarrage du service et l'interface utilisateur (pas de drapeaux).
• Ase lance Bavec FLAG_ACTIVITY_CLEAR_TOP, se Atermine.

À ce stade, le deuxième FLAG_ACTIVITY_CLEAR_TOPindicateur redémarre, Bqui se trouve dans la pile des tâches. Je suppose que cela doit détruire le Tasket en commencer un nouveau, ce qui cause mon problème, ce qui est une situation très difficile à repérer si vous me le demandez!

Donc, si toutes mes suppositions sont correctes:

• Le Launcherseul reprend la tâche initialement créée
• FLAG_ACTIVITY_CLEAR_TOPva, s'il redémarre le seul restant Activity, recréer également un nouveauTask

J'ai eu le même problème sur les appareils Samsung. Après beaucoup de recherches, aucune de ces réponses n'a fonctionné pour moi. J'ai trouvé que dans le fichier AndroidManifest.xml , launchModeest défini sur singleInstance( android:launchMode="singleInstance"). La suppression de l' launchModeattribut a résolu mon problème.

Sur mon Cat s60, j'avais activé "Ne pas garder les activités" dans les options du développeur, la désactiver à nouveau m'a permis de changer d'application sans perdre l'état des applications ...

Cette solution a fonctionné pour moi:

    @Override
    public boolean onKeyUp(int keyCode, KeyEvent event) {
        if (keyCode == KeyEvent.KEYCODE_BACK) {
            Intent startMain = new Intent(Intent.ACTION_MAIN);
            startMain.addCategory(Intent.CATEGORY_HOME);
            startMain.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
            startActivity(startMain);
            return false;
        }
        else
            return super.onKeyUp(keyCode, event);
    }

crédit: j'ai besoin de minimiser l'application Android au clic sur le bouton Retour

peut ne pas fonctionner sur tous les appareils, mais crée avec succès le comportement du bouton d'accueil lorsque vous appuyez sur le bouton Précédent, arrêtant ainsi l'activité plutôt que de la terminer.

J'ai eu le même problème, la cause était:

(Code Kotlin, dans MainActivity)

override fun onBackPressed() {
    finish()
}

Donc, lorsque je navigue vers ma MainActivity depuis ma LoginActivity, j'utilise ceci:

    val intent = Intent(this, MainActivity::class.java)
    intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP)
    intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK)
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
    startActivity(intent)

Lorsque j'utilise ces drapeaux, je n'ai pas besoin d'avoir un onBackPressed () dans ma MainActivity, cela quittera naturellement l'application lors du clic arrière. Et lorsque vous appuyez sur le bouton Accueil et que vous revenez dans l'application, il ne redémarre pas.

Solution pour les personnes qui n'ont aucune idée de la programmation et qui rencontrent ce problème dans leur téléphone Android. Cela se produit principalement en raison de la mise à niveau de la version Android (seulement mon hypothèse). Après la mise à niveau, toutes vos applications sont optimisées pour utiliser moins de batterie. Mais cela ralentit à son tour votre appareil.

Comment résoudre

Accédez aux paramètres >> Applications >> paramètres des applications (recherchez le signe des paramètres n'importe où sur l'écran - c'est différent sur différents appareils) >> optimisation de la batterie (ou opti similaire [entrez la description de l'image ici] [1] sur) >> tout déplacer applications à l'état `` non optimisé '' (doivent faire 1 par 1 manuellement - peut être autorisé / interdit sur certains téléphones). Votre application de lancement doit être `` non optimisée '' (lanceur Zen UI dans mon cas - c'est le coupable je suppose - vous pouvez essayer d'optimiser / de ne pas optimiser et de redémarrer une autre application si vous en avez le temps). Redémarrez maintenant votre téléphone. (pas besoin de réinitialiser les données / le mode sans échec ou tout problème)

Essayez le multitâche maintenant. :) Appuyer sur l'icône du lanceur devrait maintenant entraîner la reprise de la tâche en cours. :) Votre appareil deviendra Ne vous inquiétez pas de la batterie, elle se déchargera quand même.

Inestimable pour vos utilisateurs. Le CV parfait même après des semaines passées dans la liste des applications récemment utilisées.

Cela ressemble à un curriculum vitae pour l'utilisateur, mais en réalité, c'est un démarrage complet.

Contexte: la mémoire utilisée par les applications de l'activité principale qui n'ont pas démarré de tâche est facile à récupérer. Le système d'exploitation peut simplement redémarrer l'application avec le bundle d'origine passé à onCreate. Vous pouvez cependant ajouter à l'ensemble d'origine onSaveInstanceStateafin que lorsque votre application est redémarrée par le système d'exploitation, vous pouvez restaurer l'état de l'instance et personne n'est plus sage quant au redémarrage ou à la reprise de l'application. Prenons par exemple le programme de carte classique. L'utilisateur se déplace vers une position sur la carte, puis appuie sur la touche d'accueil. Deux semaines plus tard, cette application de cartographie figure toujours dans la liste des applications récentes avec Facebook, Pandora et Candy Crush. Le système d'exploitation n'enregistre pas seulement le nom de l'application pour les applications récemment utilisées, il enregistre également l'ensemble d'origine utilisé pour démarrer l'application. Cependant, le programmeur a codé leonSaveInstanceState méthode pour que le bundle d'origine contienne désormais tous les matériaux et informations nécessaires à la construction de l'application pour qu'il ressemble à sa reprise.

Exemple: Enregistrez la position actuelle de la caméra dans onSaveInstanceState au cas où l'application serait déchargée et devrait être redémarrée des semaines plus tard à partir de la liste des applications récentes.

@Override
    public void onSaveInstanceState(Bundle savedInstanceState) {
        super.onSaveInstanceState(savedInstanceState);
        // save the current camera position;
        if (mMap != null) {
            savedInstanceState.putParcelable(CAMERA_POSITION,
                    mMap.getCameraPosition());
        }
    }



@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // get the exact camera position if the app was unloaded.
        if (savedInstanceState != null) {
            // get the current camera position;
            currentCameraPosition = savedInstanceState
                    .getParcelable(CAMERA_POSITION);
        }

Remarque: vous pouvez également utiliser la onRestoreInstanceStateméthode, mais je trouve plus facile de restaurer l'instance dans onCreate.

C'est probablement ce qui se passe dans votre application. Sur certains appareils, votre application est déchargée pour libérer de la mémoire. Oui, il y a des drapeaux qui aident, mais les drapeaux ne capteront pas toutes les nuances de votre application et les drapeaux ne vous garderont pas en vie pendant des semaines comme le onSaveInstanceStatefera la volonté. Vous devez coder le CV parfait deux semaines plus tard. Ce ne sera pas une tâche facile pour l'application complexe, mais nous sommes derrière vous et nous sommes là pour vous aider.

Bonne chance