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

194

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.

Graeme
la source
1
Cela peut sembler une question triviale à poser, mais avez-vous défini "Ne pas garder les activités" sur true dans vos options de développement pour le Xoom?
Andrew Schuster
Non (je le souhaite! :)) - J'ai enregistré le cycle de vie de chaque activité et les activités en arrière-plan comme toujours disponibles (elles sont arrêtées - pas détruites). L'OS semble les invoquer finish()dans les cas où il recommence le premier Activityau lieu de les reprendre.
Graeme
1
Si vous avez appuyé sur le bouton d'accueil, puis cliquez sur l'icône du lanceur, le comportement de reprise est la valeur par défaut pour Android, comme vous le savez probablement. Cependant, si vous appuyez sur le bouton Retour pour revenir à l'écran d'accueil, la plupart des téléphones termineront () l'application. Est-il possible que la méthode que vous utilisez pour quitter l'application soit différente sur les différents appareils? Pourriez-vous vous déconnecter de onKeyUpEvent pour vérifier que certains ne gèrent pas étrangement les touches matérielles / logicielles?
Nick Cardoso
2
Non - je suis sûr du problème comme indiqué ci-dessus. Utiliser home pour mettre l'application en arrière-plan (pas en arrière, ce que vous avez raison terminerait () l'activité). Il est possible sur le Xoom de reprendre l'application à partir de la liste des tâches (tout simplement pas à partir du lanceur) afin que le backstack n'ait définitivement pas été tué.
Graeme
1
Répondre avec la prime est le moyen de résoudre le problème décrit dans la question. Marqué ma propre réponse comme "correcte" car bien que parfois le problème soit causé par un bogue d'application dans le lanceur (comme indiqué dans sa réponse), mon problème particulier était dû au changement de tâche. La solution aux deux problèmes est fixée par sa solution.
Graeme

Réponses:

238

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;
    }
starkej2
la source
4
Jusqu'à présent, cela fonctionne pour moi sans effets secondaires indésirables jusqu'à présent. Sur la base des hypothèses logiques, je ne vois aucune raison pour laquelle ce n'est pas valide.
javahead76
3
Je pense que c'est la bonne façon de gérer ce bug. Travaille pour moi.
Sokolov
3
a fait le travail pour moi, vérifié sur environ 8 appareils différents. Merci beaucoup!
shaya ajzner
3
WOOOOOW a résolu mon problème depuis que je cherchais une solution depuis 2 heures
Jean Raymond Daher
2
Merci @ starkej2. A fonctionné comme un charme.
Rajeev Sahu
54

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.)

Rich Ehmer
la source
4
"Le problème disparaît une fois que l'application a été démarrée à froid à partir du lanceur." C'est la partie la plus étrange et je l'ai également observée - tuant l'application après le premier lancement, elle recommence à se comporter normalement. Un tel bug étrange. Merci de l'analyser si profondément et pour la solution.
Odé
11
Remarque: vous pouvez obtenir que le problème se reproduise à nouveau après l'avoir initialement effacé (en "démarrant à froid" comme vous l'avez décrit) en utilisant "Ouvrir" à partir de la page Google Play de l'application, même si vous avez installé l'APK via Android Studio . J'ai trouvé cela très utile pour vérifier que le correctif avait fonctionné.
Odé
Belle explication!
karanatwal.github.io
Merci pour cette explication :)
AndroidEnthusiast
2
Cela se produit avec de nombreuses applications. Google Photos étant l'un des principaux que j'ai testé.
Raghubansh Mani
19

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
Graeme
la source
FLAG_ACTIVITY_CLEAR_TOP ne crée pas de nouvelle tâche ni ne redémarre l'activité que vous essayez de démarrer s'il s'agit de la seule activité restante. "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 en haut) ancienne activité comme nouvelle intention. "
starkej2
2
Je me rends compte que ce n'est pas censé le faire - mais par essais et erreurs, cela se produit dans mon cas. La suppression de ces indicateurs résout le problème.
Graeme
Cela ne crée pas un CV parfait sur tous les appareils dans toutes les conditions.
danny117
La suppression des drapeaux a résolu le problème pour moi. Merci
Sealer_05
J'ai un écran de démarrage / scénario principal, mais je n'utilise aucun indicateur pour passer du démarrage au démarrage, le problème est toujours reproductible pour moi - cette solution ne fonctionne pas pour moi.
ROR
12

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.

Ali
la source
En effet, cela a aussi fait l'affaire pour moi. J'ai trouvé cette réponse d'une autre question SO utile: stackoverflow.com/a/21622266/293280 . Et cette description des différents types de launchModevaleurs: inthecheesefactory.com/blog/…
Joshua Pinter
Cette correction a fonctionné pour moi! Ajout de cet attribut non pas dans le manifeste mais dans l'activité sur la classe d'activité principale.
Calin Vlasin
@CalinVlasin pourriez-vous me montrer exactement comment vous avez utilisé le launchMode? où l'avez-vous placé? actuellement, je l'ai comme ça, mais cela cause le problème: <activity android: name = ". UI.landing.MyActivity" android: configChanges = "locale | layoutDirection" android: launchMode = "singleTop" android: windowSoftInputMode = "stateAlwaysHidden | adjustResize ">
j2emanue
C'était aussi mon problème. Je pense que cela devrait être utilisé conjointement avec la réponse acceptée (! IsTaskRoot ...
behelit
1

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 ...

ptp
la source
Je ne sais pas comment, mais c'était activé sur mon appareil.
realPro
0

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.

Russell Chisholm
la source
Astuce intéressante mais ne résout pas le problème comme indiqué. Très utile pour d'autres problèmes / questions.
Graeme
Le bouton Retour a un objectif spécifique et les utilisateurs s'attendent à ce que le bouton Retour fasse ce qu'il est censé faire. Le remplacer de quelque façon que ce soit est faux et, à mon avis, très peu professionnel.
Bugs Happen
-1

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.

Christer
la source
-2

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.

Arun Antony
la source
-8

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

danny117
la source
Cela n'est pas dû à des problèmes de mémoire courants ou à des conditions par défaut d '"état de pause". J'ai essayé mon application sur de nombreux appareils (certains avec une grande mémoire, certains avec une mémoire inférieure).
Graeme
C'est pourquoi vous enregistrez des données persistantes dans onPause J'ai essayé que mon application reprenne aussi longtemps que deux semaines sur le téléphone que j'utilise tous les jours et laissez-moi vous dire après deux semaines que la méthode onCreate est appelée et que le système d'exploitation passe dans le bundle dans lequel j'ai enregistré onSaveSessionState et j'utilise les données du bundle pour faire apparaître mon activité exactement comme je l'ai laissée. Cela ne fait donc que trois jours depuis ma réponse, il n'y a donc aucun moyen que vous ayez pu terminer un test de deux semaines. Résumé: L'application peut être fermée à tout moment en arrière-plan.
danny117
@ danny117 Je ne pense pas que vous ayez une compréhension précise du problème rencontré par Graeme
starkej2
Je comprends le problème de Graeme. Sur certains appareils, la reprise de l'application appelle onCreate. Sonne exactement comme mon HTC EVO (Gingerbread) qui tuerait l'application juste pour faire pivoter l'écran. Regardez les documents qu'il dit pour que l'application puisse être restaurée dans onCreate developer.android.com/reference/android/app/…
danny117
@ danny117 c'est correct, mais le problème qu'il rencontre n'est pas lié à une seule activité en cours de recréation lorsque l'application est reprise (ce qui est attendu), mais la mauvaise activité est en cours de démarrage
starkej2