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 Activity
avec l'action android.intent.action.MAIN
et 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,
Activity
indé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 Activity
ne 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.
la source
finish()
dans les cas où il recommence le premierActivity
au lieu de les reprendre.Réponses:
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:
la source
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:
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'indicateur
Intent.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':
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.
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.)
la source
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
Activity
ou, si unTask
dé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 nouveauTask
etfinish
l'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
Task
est 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
:Bien qu'il soit assez évident que cela
FLAG_ACTIVITY_NEW_TASK
crée un nouveauTask
, 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:Mon écran de démarrage commençait le "principal"
Activity
dans mon application en utilisant le drapeau ci-dessus. Après tout, si j'avais "redémarré" mon application et que celle-ciActivity
fonctionnait 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
:J'ai donc eu la situation décrite ci-dessous:
A
lancéB
avecFLAG_ACTIVITY_CLEAR_TOP
,A
finitions.B
souhaite redémarrer un service envoie donc l'utilisateurA
auquel a la logique de redémarrage du service et l'interface utilisateur (pas de drapeaux).A
se lanceB
avec FLAG_ACTIVITY_CLEAR_TOP, seA
termine.À ce stade, le deuxième
FLAG_ACTIVITY_CLEAR_TOP
indicateur redémarre,B
qui se trouve dans la pile des tâches. Je suppose que cela doit détruire leTask
et 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:
Launcher
seul reprend la tâche initialement crééeFLAG_ACTIVITY_CLEAR_TOP
va, s'il redémarre le seul restantActivity
, recréer également un nouveauTask
la source
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 ,
launchMode
est défini sursingleInstance
(android:launchMode="singleInstance"
). La suppression de l'launchMode
attribut a résolu mon problème.la source
launchMode
valeurs: inthecheesefactory.com/blog/…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 ...
la source
Cette solution a fonctionné pour moi:
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.
la source
J'ai eu le même problème, la cause était:
(Code Kotlin, dans MainActivity)
Donc, lorsque je navigue vers ma MainActivity depuis ma LoginActivity, j'utilise ceci:
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.
la source
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.
la source
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
onSaveInstanceState
afin 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.
Remarque: vous pouvez également utiliser la
onRestoreInstanceState
méthode, mais je trouve plus facile de restaurer l'instance dansonCreate
.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
onSaveInstanceState
fera 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
la source