Lösen Sie das Problem, dass einige Mobiltelefone obb nicht lesen können

      Kürzlich wurde festgestellt, dass bei einer kleinen Anzahl ausländischer Spieler nach dem Herunterladen des Spiels aus dem Google Play Store ein schwarzer Bildschirm angezeigt wurde. Bei der Überprüfung des Fehlerprotokolls von bugly haben wir festgestellt, dass das Lesen der obb-Datei fehlgeschlagen ist. Der Google Store schreibt vor, dass APKs mit mehr als 100 MB separat in obb hochgeladen werden müssen. Daher wird diese Situation nur im Spielepaket im Google Store angezeigt.
      Das Lesen von obb in meinem Projekt ist in zwei Situationen unterteilt: Die erste ist das Lesen über die eigene API von Unity, beispielsweise die Methode Resources.Load(). Die andere Möglichkeit besteht darin, den Pfad der OBB-Datei über die ursprüngliche Java-Methode zu ermitteln und die OBB-Datei dann über die Methode getInputStream als ZIP-Paket zu lesen.
      Nach verschiedenen Ausschlüssen wurde festgestellt, dass bei einigen bestimmten Modellen, wenn die Berechtigung READ_EXTERNAL_STORAGE (externen Speicher lesen) verboten ist, eine Situation auftritt, in der der externe Speicher nicht gemountet ist und der Fehler von der Methode Environment.getExternalStorageState() zurückgegeben wird ist „unmontiert“.
In diesem Fall ist der durch getObbDir() erhaltene Pfad nicht zugänglich, sodass die obb-Datei nicht geladen werden kann. Das Erstaunliche ist, dass der erhaltene Pfad betriebsbereit ist, wenn Sie obb nicht verwenden und einfach Unitys eigenen Application.persistentDataPath verwenden. Nach normalem Verständnis befindet sich dieser Pfad in data/storage/emulated/0/Android/data/com.xxx .xxx/files, und der Pfad von obb befindet sich im Allgemeinen unter data/storage/emulated/0/Android/obb/com.xxx.xxx. Könnte es sein, dass Android/data/ keine Berechtigungen erfordert, Android/obb/ jedoch schon ?
      Bei dieser Frage habe ich versucht, Application.persistentDataPath mithilfe von OnGUI in Unity anzuzeigen, und habe dann die Berechtigung READ_EXTERNAL_STORAGE geöffnet bzw. deaktiviert. Endlich das Problem gefunden.
Wenn eine Leseberechtigung vorliegt, ist der Standardpfad, auf den die Anwendung zugreift, der Ordner data/storage/emulated/0/Android/.
Wenn Lese- und Schreibberechtigungen verboten sind, ist der Zugriff auf das Speicherverzeichnis, das sogenannte nicht gemountete Verzeichnis, verboten. Daher wird ein anderes Verzeichnis als Standardzugriffsverzeichnis des Programms verwendet: data/user/0/, wobei 0 die Seriennummer des Benutzers ist. Es heißt, dass Android nach 6.0 mehrere Benutzer unterstützt, daher gibt es diesen Ordner.
      Die API von Unity sollte unabhängig von normalen Ressourcen zum Lesen von obb sein. PersistentDataPath kann den Pfad normal abrufen, aber der Pfad von obb wird schätzungsweise über Methoden wie getObbDir abgerufen, sodass auf den Pfad nicht zugegriffen werden kann und das Laden von obb fehlschlägt.
      Was wir besprochen haben, sind einige spezielle Mobiltelefone. Normale Mobiltelefone werden nicht so sein. Normale Mobiltelefone können nach dem Deaktivieren der READ_EXTERNAL_STORAGE-Berechtigung weiterhin normal auf den Ordner data/storage/emulated/0/Android/ zugreifen. Environment.getExternalStorageState( ) wird auch „montiert“. Dann treten solche Probleme natürlich nur bei Mobiltelefonen mit Android 6.0 und höher auf, da Mobiltelefone unter 6.0 nicht über die Möglichkeit verfügen, Berechtigungen dynamisch zu beantragen.
      Also habe ich versucht, die Erlaubnis zu bekommen, dieses Problem zu lösen. Die normale Idee ist sehr einfach. Sie müssen nur zu Beginn des Spiels beurteilen, ob Sie über diese Berechtigung verfügen. Wenn Sie nicht über die Berechtigung verfügen, wird ein Popup-Fenster zur dynamischen Berechtigungsanwendung angezeigt, in dem der Benutzer aufgefordert wird, der Berechtigung zuzustimmen die Autorisierung.
      Im tatsächlichen Betrieb wurde jedoch festgestellt, dass für diesen Teil des Mobiltelefons, wenn der Berechtigungsautorisierungsstatus in den Einstellungen verboten ist, das Autorisierungsfenster überhaupt nicht angezeigt wird und die Ablehnung direkt zurückgegeben wird. In diesem Fall gehe ich persönlich davon aus, dass Systeme nach Android 6.0 im Allgemeinen über drei Arten von Berechtigungen verfügen: Erlauben, Fragen und Verbieten. Beim Deaktivieren gibt es normalerweise eine kleine Option: „Nach dem Deaktivieren nicht erneut auffordern.“ In dem Mobiltelefonsystem, in dem das Problem aufgetreten ist, wird dieser Status jedoch nicht abgefragt. Wenn er in den Einstellungen deaktiviert ist, wird im Gegenzug nach der Deaktivierung keine Aufforderung mehr angezeigt.
      Daher können wir dieses Problem immer noch nicht über das Berechtigungs-Popup-Fenster lösen. Wir können Spielern helfen, zum Einstellungsfeld des Mobiltelefons zu springen und es Spielern ermöglichen, Einstellungen manuell zu ändern. Die Sprungmethode lautet:
Intent myAppSettings = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.parse("package:" + getPackageName()));
startActivityForResult(myAppSettings, REQUEST_APP_SETTINGS);
Dieser Vorgang ist jedoch weder benutzerfreundlich noch geeignet für Spieler. Sie müssen wissen, wie man es bedient.
      Letztendlich möchten wir den Schaden minimieren, sodass die meisten normalen Spieler weiterhin Berechtigungen über das Berechtigungs-Popup-Fenster autorisieren können und einer kleinen Anzahl von Benutzern, die das Popup-Fenster nicht kennen, den Sprung ermöglichen das Einstellungsfeld des Mobiltelefons. Daher können wir über Berechtigungen nicht direkt feststellen, ob ein Popup-Fenster benötigt wird. Glücklicherweise haben wir bei der vorherigen Beurteilung der Montagemethode festgestellt, dass das Merkmal dieser Art von Mobiltelefonen darin besteht, dass die Montagemethode „nicht gemountet“ ist, wenn die Berechtigung zum Lesen externer Speicher verboten ist, sodass wir sie zunächst anhand der Verwendung beurteilen können die Montageart. Wenn „nicht gemountet“ gefunden wird, wird der Player aufgefordert, die Autorisierung manuell festzulegen.