Résolvez le problème selon lequel certains téléphones mobiles ne parviennent pas à lire obb

      Récemment, il a été découvert qu'un petit nombre de joueurs étrangers avaient un écran noir après avoir téléchargé le jeu depuis le Google Play Store. En vérifiant le journal des erreurs de bugly, nous avons constaté que la lecture du fichier obb avait échoué. Google Store stipule que les apk dépassant 100 millions doivent être téléchargés séparément dans obb. Cette situation n’apparaîtra donc que dans le package du jeu sur le Google Store.
      La lecture d'obb dans mon projet est divisée en deux situations. La première consiste à lire via la propre API de Unity, telle que la méthode Resources.Load(). L'autre consiste à trouver le chemin du fichier obb via la méthode Java d'origine, puis à lire le fichier obb sous forme de package zip via la méthode getInputStream.
      Après diverses exclusions, il a été constaté que pour certains modèles spécifiques, lorsque l'autorisation READ_EXTERNAL_STORAGE (lecture du stockage externe) est interdite, il y aura une situation dans laquelle le stockage externe n'est pas monté et l'erreur renvoyée par la méthode Environment.getExternalStorageState() est "démonté".
Dans ce cas, le chemin obtenu par getObbDir() ne sera pas accessible, donc le fichier obb ne pourra pas être chargé. Ce qui est étonnant, c'est que si vous n'utilisez pas obb et utilisez simplement le propre Application.persistentDataPath de Unity, le chemin obtenu est exploitable. Selon la compréhension normale, ce chemin est dans data/storage/emulated/0/Android/data/com.xxx .xxx/files, et le chemin d'obb est généralement sous data/storage/emulated/0/Android/obb/com.xxx.xxx. Se pourrait-il qu'Android/data/ ne nécessite pas d'autorisations, mais Android/obb/ le fait ?
      Avec cette question, j'ai essayé d'afficher Application.persistentDataPath en utilisant OnGUI dans l'unité, puis j'ai respectivement ouvert et désactivé l'autorisation READ_EXTERNAL_STORAGE. J'ai enfin trouvé le problème.
Lorsqu'il y a une autorisation de lecture, le chemin par défaut auquel l'application accède est le dossier data/storage/emulated/0/Android/.
Lorsque les autorisations de lecture et d'écriture sont interdites, l'accès au répertoire de stockage est interdit, ce qu'on appelle non monté, il sera donc alloué Un autre répertoire est utilisé comme répertoire d'accès par défaut du programme : data/user/0/ où 0 est le numéro de série de l'utilisateur. On dit qu'Android prend en charge plusieurs utilisateurs après 6.0, il y a donc ce dossier.
      L'API de Unity doit être indépendante des ressources normales pour lire obb. PersistentDataPath peut obtenir le chemin normalement, mais on estime que le chemin d'obb est obtenu via des méthodes telles que getObbDir, donc le chemin n'est pas accessible et le chargement d'obb échoue. .
      Nous avons discuté de certains téléphones mobiles spéciaux. Les téléphones mobiles normaux ne seront pas comme ça. Les téléphones mobiles normaux peuvent toujours accéder au dossier data/storage/emulated/0/Android/ normalement après avoir désactivé l'autorisation READ_EXTERNAL_STORAGE. Environment.getExternalStorageState( ) soyez également "monté". Ensuite, bien sûr, ce type de problème n'apparaîtra que sur les téléphones mobiles équipés d'Android 6.0 et supérieur, car les téléphones mobiles inférieurs à 6.0 n'ont pas la possibilité de demander dynamiquement des autorisations.
      Essayez donc d'obtenir la permission pour résoudre ce problème. L'idée normale est très simple. Il vous suffit de juger si vous disposez de cette autorisation au démarrage du jeu. Si vous n'avez pas l'autorisation, une fenêtre contextuelle pour l'application d'autorisation dynamique apparaîtra pour demander à l'utilisateur d'accepter. l'autorisation.
      Cependant, en fonctionnement réel, il a été constaté que pour cette partie du téléphone mobile, si l'état d'autorisation dans les paramètres est interdit, la fenêtre d'autorisation n'apparaîtra pas du tout et renverra directement un rejet. Dans ce cas, je suppose que les systèmes postérieurs à Android 6.0 disposent généralement de trois types d'autorisations : autoriser, demander et interdire. Lors de la désactivation, il existe généralement une petite option : "Ne plus demander après la désactivation". Cependant, dans le système de téléphonie mobile où le problème est survenu, il n'y a en fait aucune demande concernant cet état. S'il est désactivé dans les paramètres, l'effet équivalent est qu'il ne vous demandera plus après l'avoir désactivé.
      Par conséquent, nous ne pouvons toujours pas résoudre ce problème via la fenêtre contextuelle d’autorisation. Nous pouvons aider les joueurs à accéder au panneau des paramètres du téléphone mobile et leur permettre de modifier manuellement les paramètres. La méthode de saut est la suivante :
Intent myAppSettings = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.parse("package:" + getPackageName()));
startActivityForResult(myAppSettings, REQUEST_APP_SETTINGS);
Mais cette opération n'est ni conviviale ni adaptée. pour les joueurs. Il faut savoir fonctionner.
      En fin de compte, ce que nous voulons réaliser est de minimiser les dégâts, de sorte que la plupart des joueurs normaux puissent toujours autoriser les autorisations via la fenêtre contextuelle d'autorisation, et permettre à un petit nombre d'utilisateurs qui ne connaissent pas la fenêtre contextuelle d'y accéder. le panneau des paramètres du téléphone mobile. Par conséquent, nous ne pouvons pas déterminer directement si une fenêtre contextuelle est nécessaire via les autorisations. Heureusement, lorsque nous évaluions auparavant la méthode de montage, nous avons découvert que la caractéristique de ce type de téléphone mobile est que si l'autorisation de lecture du stockage externe est interdite, la méthode de montage est "démontée", nous pouvons donc utiliser la méthode de montage pour juger d'abord. Si "démonté" est trouvé, le joueur sera invité à définir manuellement l'autorisation.