Zmiany w zakresie pamięci masowej w systemie Android Q przyprawiają o ból głowy, ponieważ struktura dostępu do pamięci masowej ma obecnie kilka wad.
Android Q zasadniczo zmienia sposób działania pamięci w telefonie. W każdej wersji, aż do Pie, pamięć Androida działała jak komputer stacjonarny: możesz używać dowolnej aplikacji, którą chcesz czytać lub zapisywać dowolny plik (jeśli udzielisz na to uprawnień aplikacji). Dzięki Q Google wprowadza (i wymaga) „Magazynowanie o ograniczonym zakresie”, co sprawia, że Android działa bardziej jak iPhone, w którym pamięć jest oddzielna dla każdej aplikacji. Aplikacja może uzyskać dostęp tylko do swoich plików, a jeśli zostanie odinstalowana, wszystkie jej pliki zostaną usunięte.
Na szczęście Android Q nadal zachowuje część oryginalnego zachowania Androida w postaci centralnego systemu plików. Niestety, obecnie konfigurowanie aplikacji zapewniających dostęp do niego jest dla użytkownika uciążliwe, co znacznie zmniejsza wydajność i możliwości. Programiści będą musieli znacznie przekodować aplikacje, aby je obsługiwać.
Aplikacje wymagające ogólnego dostępu do systemu plików, np. pakiet biurowy, edytor obrazów lub menedżer plików będzie teraz musiał korzystać z interfejsu API systemu Android o nazwie „Struktura dostępu do pamięci masowej" (SAF), dla wszystkich operacji na plikach. SAF jest dostępny od wersji Androida 5.0 Lollipop, ale programiści zwykle nie używają go, chyba że jest to wymagane, ponieważ ma on trudny i słabo udokumentowane API, kiepskie doświadczenie użytkownika, słaba wydajność i słaba niezawodność (głównie w postaci implementacji specyficznej dla dostawcy urządzenia kwestie). W związku z trudnościami w przejściu na SAF firma Google zdecydowała się zezwolić na aplikacje, które jeszcze tego nie wskazują Obsługa Androida Q będzie działać tak jak dawniej, ale to się zmieni, gdy Sklep Play wymaga, aby wszystkie aplikacje obsługiwały Q Następny rok.
Najbardziej oczywistą zmianą, na którą zwraca uwagę użytkownik w SAF, jest możliwość przyznania aplikacji dostępu do pamięci masowej. Aby aplikacja mogła uzyskać dostęp, wysyła żądanie do systemu operacyjnego, który następnie wyświetla ekran wyboru katalogu. Na tym ekranie użytkownik wybiera katalog główny hierarchii folderów, w którym aplikacja będzie mogła odczytywać i zapisywać pliki. Użytkownik musi przejść ten proces w przypadku każdej aplikacji wymagającej dostępu do plików lokalnych lub dwukrotnie w przypadku każdej aplikacji, jeśli musi także przyznać jej dostęp do zewnętrznej karty SD.
Google przynajmniej ulepszył ten proces Q-beta 3, ponieważ wcześniejsze wersje beta nie pozwalały aplikacji nawet sugerować użytkownikowi lokalizacji, którą może wybrać wymagało od użytkownika sporo pracy aby znaleźć podstawową pamięć urządzenia.
Wydajność operacji we/wy plików jest nieco niższa w przypadku SAF, ale najważniejszy problem leży w plikach operacje na katalogach, gdzie jest to od ~25 do 50 razy wolniejsze niż w przypadku konwencjonalnego dostępu do plików Ciasto. W przypadku menedżerów plików oznacza to, że wyszukiwanie i obliczanie wykorzystania pamięci zajmie o rząd wielkości więcej czasu. Raport o błędzie dotyczący aplikacji demonstracyjnej to dostępny tutaj.
Jeszcze większym problemem z wydajnością jest to, że niektóre aplikacje będą musiały skopiować pliki do lokalnego obszaru „pamięci o określonym zakresie”, zanim będą mogły z nimi pracować. Może to być problematyczne, gdy takie pliki mają rozmiar wielu gigabajtów, np. w przypadku plików wideo lub skompresowanych archiwów. Wiele aplikacji na Androida korzysta z niesamowitej liczby bibliotek Java typu open source dostępnych w społeczności programistów, a biblioteki te często wymagają do działania bezpośredniego dostępu do systemu plików. Nie są one specyficzne dla Androida i wymagałyby przepisania, aby działały z SAF. Co gorsza, wiele wewnętrznych bibliotek Androida, takich jak menedżer pakietów lub API zip, nie będzie z nim działać. Na przykład menedżer plików nie będzie w stanie wyświetlić ikony pliku APK (przy użyciu standardowego interfejsu API systemu Android) bez uprzedniego skopiowania całego pliku APK do własnego obszaru przechowywania. Zgłoszenie błędu.
Dla osób o technicznych zdolnościach możliwe jest obecnie wyłączenie „Scoped Storage” w systemie Android Q dla poszczególnych aplikacji za pośrednictwem ADB za pomocą polecenia appops. Użytkownicy root mogą wykonywać polecenia bezpośrednio na swoim urządzeniu bez komputera stacjonarnego. Takie polecenia są opisane w dokumentacji jako funkcje programistyczne i dlatego mogą zostać usunięte w dowolnym momencie.
Włącz ogólny dostęp do pamięci dla aplikacji:
adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-nameWyłącz ogólny dostęp do pamięci dla aplikacji:
adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-nameGoogle zachwala korzyści wynikające z tej zmiany w zakresie bezpieczeństwa i prywatności, ale technicznie rzecz biorąc, nie ma poprawy. Od wersji Androida 1.0 aplikacje umożliwiają prywatne przechowywanie plików i prawie wszystkie aplikacje korzystają z tej możliwości. Gdy przyznasz aplikacji dostęp do katalogu głównego pamięci za pośrednictwem SAF, będzie ona mogła czytać, zapisywać i wysyłać dowolne pliki chce wobec swojego nikczemnego programisty dokładnie w taki sam sposób, w jaki mógłby to zrobić, przyznając aplikacji dostęp do pamięci w Pie.
Jedyna „poprawa bezpieczeństwa” następuje dlatego, że jest to teraz bardziej uciążliwy proces dla użytkownika. Chyba że aplikacja chce tylko ukraść Twoje najbardziej osobiste dane, takie jak zdjęcia i filmy podjęte, dla którego Google dodał alternatywne rozwiązanie dostępu, które wykorzystuje proste zabezpieczenie typu „kliknięcie” w wyskakującym okienku dialog.
Nie wiadomo, jakie korzyści Google chce osiągnąć dzięki tej zmianie. Oficjalnym powodem podanym w dokumentacji wersji beta Androida Q jest „zapewnienie użytkownikom większej kontroli nad plikami i ograniczenie ich nieład." Magazynowanie ograniczone w obecnej formie stanowi nowe ograniczenie tego, co użytkownik może zrobić, a nie jego rozszerzenie kontrola. Twierdzenie o ograniczeniu bałaganu może być w pewnym stopniu uzasadnione, ale tylko dlatego, że zmiana w ogóle ogranicza możliwość korzystania z plików. A „bałagan” wzrasta, gdy weźmie się pod uwagę problem polegający na tym, że niektóre aplikacje muszą teraz duplikować pliki, aby z nimi pracować.
Jeśli Google naprawdę zależy na zapewnieniu użytkownikom większej kontroli nad plikami i bałaganem, powinien zaprojektować plik a rozwiązanie, które bezpośrednio rozwiązuje ten problem, zamiast fałszywie promować obecny projekt Androida Q jako taki poprawa. Najprostszą odpowiedzią byłoby umożliwienie użytkownikom decydowania, czy chcą, aby aplikacja miała dostęp ograniczony czy ogólny do systemu plików, za pomocą okna dialogowego z prośbą o pozwolenie na istniejącą pamięć masową. Jeśli istnieje szczególna obawa, że użytkownicy podejmują tutaj złe decyzje, z pewnością jest to możliwe zwiększ widoczność tego okna dialogowego i wymagaj dodatkowej interakcji użytkownika, aby w pełni zatwierdzić aplikację dostęp.
Odpowiedzią na to, w jaki sposób Android może zapewnić użytkownikom większą kontrolę nad plikami, jest zapewnienie im większej kontroli, a nie odebranie jej i zasadniczo ograniczenie możliwości platformy Android.
Nota wydawcy: To jest artykuł gościnny napisany przez starszego członka XDA Tliebeck, najbardziej znany ze swojej pracy nad Eksplorator plików FX. Treść tego artykułu odzwierciedla jego własną opinię i analizę ograniczeń dotyczących ograniczonej pamięci masowej systemu Android Q, przy minimalnym wkładzie i edycji dokonanej przez Mishaala Rahmana, redaktora naczelnego XDA-Developers. Skontaktowaliśmy się z Google, aby zapytać o niektóre z tych obaw, ale do czasu publikacji nie otrzymaliśmy odpowiedzi od firmy.