Pourquoi mon onResume être appelé deux fois?
Fondamentalement, ce est ce que je fais
1) Définir AlarmManager pour exécuter BroadcastReceiver (BCR)
Intent intent = new Intent(m_Context, BCR.class);
intent.putExtras(extras);
PendingIntent pendingIntent = PendingIntent.getBroadcast(m_Context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
AlarmManager am = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
am.set(AlarmManager.RTC_WAKEUP, StartTime, pendingIntent)
2) Démarrer MyActivity de BCR
@Override
public void onReceive(Context context, Intent intent) {
Intent newIntent = new Intent(context, MyActivity.class);
newIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);
context.startActivity(newIntent);
}
3) Ont MyActivity allumer l'écran si ce n'est pas sur
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
getWindow().addFlags(LayoutParams.FLAG_DISMISS_KEYGUARD);
getWindow().addFlags(LayoutParams.FLAG_SHOW_WHEN_LOCKED);
getWindow().addFlags(LayoutParams.FLAG_TURN_SCREEN_ON);
setContentView(R.layout.myactivity);
}
@Overide
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
}
Pour une raison quelconque, je remarque que la droite quand MyActivity est ouvert, c'est le flux va comme:
onCreate/onNewIntent -> onResume -> onPause -> onResume
Je ne suis pas sûr de savoir pourquoi il ne fait pas de onPause tout de suite. Je remarque que cela se produit uniquement lorsque le dépistage est activé par les drapeaux. Personne ne sait pourquoi cela se produit? Est-il possible que ce comportement peut-il être évité?
- Est-ce que votre activité de la force spécifique de l'orientation portrait ou paysage?
- Le screenOrientation est la valeur portrait pour MyActivity dans le manifeste.
Vous devez vous connecter pour publier un commentaire.
Juste au cas où quelqu'un d'autre s'exécute dans la présente, j'ai l'air de remarquer ce comportement que lorsque je me gonfler les fragments à l'intérieur d'une activité via XML de mise en page. Je ne sais pas si ce comportement se produit également avec la bibliothèque de compatibilité de version de Fragments (je suis sous android.app.Fragment)
Il semble que l'activité fera appel
Activity#onResume
une fois avant d'appelerFragment#onResume
pour tout ajout de Fragments, puis de l'appelActivity#onResume
de nouveau.Si vous avez
ES File Explorer
puis FORCER l'ARRÊT il. En quelque sorte, l'interruption de votre application lifecycle (observations suggèrent une sorte de superposition).Mon problème avec
onResume
causé deux fois parce queonPause
a été en quelque sorte d'être appelé après que l'activité a été créé.. quelque chose a été interrompu mon application.Et ce seulement qui se passe après l'ouverture de la première fois après l'installation ou construit à partir de studio.
J'ai eu le indice à partir d'un autre poste et a découvert qu'il était en raison de ES Explorateur de Fichiers. Pourquoi ne onResume() semble être appelé deux fois?
Dès que j'ai "forcer l'arrêt" ES Explorateur de Fichiers, ce hoquet de comportement ne se fait plus... c'est frustrant de savoir après avoir essayé de nombreux autres solutions proposées. Alors méfiez-vous de toute autre interrompre apps comme celui-ci.
si vous essayez de demander des autorisations à chaque fois qu'il peut provoquer de tels problèmes, il suffit de vérifier si vous avez déjà accordé leur
requestPermissions
, peuvent être la cause:PackageManager.PERMISSION_GRANTED != 0
avant de demander des autorisations a été le correctif.Je faisais des recherches sur ce sujet pendant un certain temps parce que sur internet il n'y a aucune mention au sujet de ce comportement bizarre. Je n'ai pas de solution comment surmonter ce côté sombre de la conduite, mais j'ai trouvé un scénario exact quand il se produit certainement.
onPause-onResume-onPause-onResume
arrive juste à chaque fois, lorsque l'application est en commençant la première fois après l'installation. Vous pouvez simplement appeler ce comportement en faisant tout changement dans le code et en le relançant (qui comprend la recompilation) l'application à partir de votre IDE.Peu importe si vous utilisez AppCompat libs ou pas. J'ai testé les deux cas, et le comportement se poursuit.
Remarque: Testé sur Android Guimauve.
J'ai emprunté le code de ce fil à propos du fragment et de l'activité du cycle de vie et c'est ici (il suffit de copier, de coller, de déclarer l'activité dans le manifeste et exécuter Forêt exécuter):
onResume
etonPause
. J'ai déménagé dansonStart
etonStop
.Je ne sais pas pour vous ce qui se passe, mais je soupçonne que votre activité est en cours de redémarrage, car la définition de l'écran est traité par le système comme un changement de configuration. Vous pouvez essayer de journalisation de la configuration sur chaque appel à
onResume
de voir si c'est ce qui se passe et, dans l'affirmative, ce qui est réellement en train de changer. Vous pouvez ensuite modifier le manifeste pour indiquer au système que votre activité va gérer le changement sur son propre.onResume
et B seront également appelonResume
,c'est bizarre.J'ai le même problème.
Ma situation était la suivante
CurrentActivity s'étend MainActivity
CurrentFragment s'étend MainFragment
J'ai été l'ouverture CurrentActivity avec l'intention, comme d'habitude. Dans onCreate CurrentAcitivity j'ai été remplaçant CurrentFragment.
Cycle de vie a été:
1. onResume MainActivity
2. onResume CurrentActivity
3. onResume MainFragment
4. onResume CurrentFragment
appelé onPause Automatiquement, et après cela encore
Je décide de tester à nouveau le tout et après quelques heures passées à essayer et de jouer, j'ai trouvé la racine du problème.
Dans MainFragment onStart je appeler startActivityForResult à chaque fois (dans mon cas, android popup pour allumer le Wifi) qui était d'appeler onPause sur MainFragment. Et nous savons tous qu'après onPause suivant est onResume.
Donc ce n'est pas Android bug, c'est seulement le mien 🙂
Heureux de cycle de vie de debuging!
J'ai eu un problème similaire, et mon problème était que, dans le onCreate() la méthode, j'étais en train de faire:
Mon appel à la "super." a été le déclenchement de la onResume() deux fois. Il a travaillé comme prévu après je l'ai changé pour seulement:
Espère que cela aide.
J'ai aussi rencontré ce onresume-onpause-onresume (séquence sur la 4.1.2 et au-dessus, mais je n'ai pas l'expérience de ce sur 2.3). Mon problème était lié à wakelock manipulation: j'ai malencontreusement oublié de libérer un wakelock et réacquérir il a provoqué une erreur avec un message "WakeLock finalisés toujours détenus". Ce problème a entraîné onPause être appelé immédiatement après onResume et a abouti à un comportement incorrect.
Ma suggestion: vérifier les erreurs dans le journal, ceux qui pourraient être liés à cette question.
Un autre indice: l'activation de l'écran pourrait être un peu plus compliqué que de simplement en utilisant les indicateurs de la fenêtre. Vous pourriez vouloir vérifier cette réponse ici - il suggère de vous configurer un récepteur pour vérifier si l'écran a déjà été activée et le lancement de l'activité désirée, qu'après: https://stackoverflow.com/a/16346369/875442
Il semble que l'utilisation de
Activity
à partir de la bibliothèque de prise en charge sauve et restaure instance automatiquement. Par conséquent, seulement à faire votre travail sisavedInstanceState
estnull
.Je viens de tomber sur cela, et il semble que
getWindow().addFlags()
et de peaufinageWindow
propriétés, en général, peut être un coupable.Quand mon code est comme cela
onResume()
est déclenché deux fois, mais quand j'enlèverequestWindowFeature()
, il n'est appelé qu'une seule fois.Je pense que vous devriez jeter un oeil à cette question:
Nexus 5 d'aller dormir, le mode d'activité du cycle de vie buggy
Vous devriez trouver des prospects
Fondamentalement, beaucoup de choses peuvent déclencher cette. Certains de reprendre les processus qui perd le focus peut le faire. Quelques apps va l'amener à se produire trop. La seule façon de faire face est de bloquer le double en cours d'exécution. Remarque, ce qui aura aussi un errant pause jetés pour faire bonne mesure.
C'est un solide moyen de prévenir de telles choses. Il permet de bloquer double reprend. Mais, il permet également de bloquer les deux résumés qui permettent de préserver la mémoire. Donc, si vous venez de perdre le focus et il n'a pas besoin de reconstruire votre stuff. Il bloque aussi. Ce qui pourrait être un avantage clairement, car si vous utilisez le reprendre pour le contrôle des changements au cours de la focus, vous seulement en fait de soins si vous avez besoin de reconstruire ce genre de choses à cause de l'accent. Depuis la pré-attirer les auditeurs ne peuvent être appelées que par un fil et ils doivent être appelés dans l'ordre, le code sera exécuté qu'une fois. Jusqu'à ce que quelque chose correctement détruit la totalité de l'activité et définit resumeblock dos à faux.
j'ai aussi été confronté à ce problème c'est à cause de fragments..
le nombre de fragments que vous avez dans l'activité
onResume()
appellent le nombre de fois. pour les surmonter, j'ai utilisé le drapeau variables dansSharedPrefrences
comme @TWL dit
ES Explorateur de Fichiers
la question pour moi !
La désinstallation de l'application résolu le problème.
Lorsque cette ES Explorateur de Fichiers a été installé,
onStart() -> onResume() -> onPause() -> onResume()
.. était le problème.onResume()
a été appelé 2'ce.J'ai eu le même problème. Le mien était de ce code lors de l'exécution
Je viens de le mettre dans le manifeste
pas plus de problème à propos de deux fois appel à onCreate et onResume.