Même avec "voip" présent dans "UIBackgroundModes" dans "plist", iOS App ne démarre pas automatiquement après le redémarrage de l'appareil dans iOS10

D'accord, j'ai enquêté un peu plus loin, mais d'abord je dois préciser que je n'ai pas vérifié cela en essayant réellement de build un projet pour cela, car cela prendrait trop de time pour moi maintenant.

J'ai trouvé ceci (déjà mentionné dans les commentaires), ceci , et surtout ce Q & A de technologie .

Ce que j'ai recueilli notamment sur les différents commentaires des techniciens Apple dans ces threads, il apparaît que le comportement d'iOS 10 a bien changé. Cela signifie que le même code connecté aux servers VoiP dans les versions antérieures d'iOS ne le fera plus si vous liez votre build au dernier SDK, c'est-à-dire aux bibliothèques iOS 10.

Maintenant, dans votre cas, vous n'avez pas vraiment besoin d'une vraie connection VoiP, n'est-ce pas? Vous êtes simplement intéressé par la fonctionnalité "Démarrer après le redémarrage", correct? Au less, le projet de démonstration que vous avez lié ne fait aucune connection VoiP, la setKeepAliveTimeout:handler: par exemple, n'est même pas implémentée. Je suis conscient que ce problème spécifique n'est pas abordé dans les discussions liées ou abordé dans le Q & A, MAIS:

Il est logique que, avec l'set du comportement VoiP hérité, la fonctionnalité de redémarrage disparaît également. Si vous deviez passer à Push-Kit VoiP, votre application n'aurait pas besoin d'être démarrée après un redémarrage, elle redémarrerait dès que la prochaine notification à distance arriverait (et les notifications VoiP ont une haute priorité, donc il n'y a pas de timeout).

Évidemment, je déduis ici la raison d'être de tout cela et je ne peux pas garantir qu'Apple ait réellement réfléchi, mais cela a du sens: la raison pour laquelle une application VoiP (ancienne) a été (re) lancée après un redémarrage était il fallait établir une connection , c'est-à-dire qu'il fallait exécuter du code. Avec les notifications push qui ne sont plus nécessaires (le operating system le fait en coulisse pour get ces notifications), il est donc logique qu'ils aient supprimé cette fonctionnalité avec l'set de l'approche VoiP héritée.

Vous pouvez tester cela en compilant l'ancien SDK (c'est-à-dire utiliser Xcode 7 comme le suggère le Q & R) et voir s'il se relance ensuite. Ce membre du personnel d'Apple a expliqué que le operating system distingue effectivement les SDK de construction pour les applications, ce qui est totalement contre-intuitif pour moi. Apparemment dans ce cas, il déciderait "hé, c'est une application plus ancienne, donc il s'attend à être relancé parce que son SDK a été documenté de cette façon" pour les applications construites sur Xcode 7 et "Oh, cette application est une nouvelle, donc je ne pas besoin de restr fidèle aux vieilles habitudes ". Wowsies.

TL; DR : Pour moi, il semble que oui, le SDK iOS a changé ce comportement en abandonnant l'ancienne approche VoiP sans notification. La compilation avec les nouveaux SDK entraînera la non-relance des applications après le redémarrage.

Pour memory : je peux comprendre les gens en colère dans ces discussions. Bien qu'il puisse y avoir des raisons techniques au changement, cette conséquence spécifique était loin d'être évidente. Si une méthode est déconseillée, mais que le projet se comstack et s'exécute, je ne m'attendrais pas à ce qu'un tel process échoue de cette manière. Ces applications ne tombent pas en panne, elles sont simplement "traitées différemment par le operating system", ce qui n'est pas tout à fait la même chose. Au less, je m'attendais à ce que la documentation soit plus claire à ce sujet dans le nouveau SDK.

L'application invoquera en arrière-plan lorsqu'elle est en mode terminé uniquement avec la notification silencieuse du kit de mise sous tension et que les certificates doivent être générés pour le kit de démarrage, pas avec la notification APNS normale et les certificates de notification push normaux.

De l'arrière, votre charge utile doit être comme ça.

 $body['aps'] = array( 'content-available'=> 1, 'alert' => $message, 'sound' => 'default', 'badge' => 0, ); 

Une fois que vous obtenez la charge utile pushkit, puis planifier la notification locale avec le file son, votre application sera invoquée en arrière-plan jusqu'à vos lectures de files son. (Max 30 secondes) Ensuite, vous devez terminer votre tâche en arrière-plan.

Veuillez faire reference à quelques détails importants au sujet de l'intégration du kit de démarrage étape par étape

https://github.com/hasyapanchasara/PushKit_SilentPushNotification

Cycle de vie de l'application – lorsque l'application est terminée et que la charge utile du kit de démarrage arrive

• Tout d'abord

  didFinishLaunchingWithOptions // invoquera

• alors

  didReceiveIncomingPushWithPayload méthode payload de didReceiveIncomingPushWithPayload // est didReceiveIncomingPushWithPayload

• Ensuite, si vous avez une notification locale

  didReceiveLocalNotification // reçoit une notification locale

• alors

  handleActionWithIdentifier // méthode handler si vous avez des buttons d'action (local)

• Ensuite, si vous avez une notification à distance

  didReceiveRemoteNotification // reçoit une notification à distance

• alors

  handleActionWithIdentifier // méthode du gestionnaire si vous avez des buttons d'action (à distance)

Remarque – Si vous n'appuyez pas sur l'icône de l'application ou si vous ne recevez pas la charge utile du kit de push, votre application ne sera jamais révoquée / ouverte / répétée automatiquement. Si vous voulez que votre application soit basée sur VOIP et que l'application soit révoquée après le redémarrage du périphérique. Pas possible.