Gdzie znajdują się dane usług Google Play w urządzeniu? Czy mogę to bezpiecznie usunąć?

Właśnie zauważyłem, że dane w pamięci wewnętrznej dla aplikacji usług Google Play wzrosły powyżej 100 Mb, więc ta aplikacja jest teraz oficjalnie kosmiczna.

Więc moje pytania to:

Jaka jest dokładna lokalizacja danych usług Google Play? (do tworzenia kopii zapasowych)
Czy mogę bezpiecznie usunąć dane usług Google Play i pozwolić aplikacji na ich ponowne utworzenie?
Co mogę stracić, jeśli nieumyślnie usunę dane usług Google Play?

google-play-services app-data

— Bezpłatne konsultacje
źródło

Cześć! Odzwierciedlałem w tytule niektóre poruszone przez ciebie punkty i usunąłem niektóre tagi, ponieważ nie były one specyficzne dla pytania. Mam nadzieję, że to OK!

— Firelord

@ Firelord, jestem tu raczej nowy, więc dla mnie to w porządku. W końcu mam rozwiązanie jakościowe dla mojego pytania (jeszcze raz dziękuję!). Zrobiłem tę zupę tylko dlatego, że Play Services przyciągnęły moją uwagę jako kosmiczny świnia, moje urządzenie 4.2.2 ma tylko 1 GB pamięci wewnętrznej, więc zawsze martwię się o wolne miejsce.

— Bezpłatne konsultacje

Jaka jest dokładna lokalizacja danych usług Google Play?

Nazwa pakietu usług Google Play to com.google.android.gms.

Domyślny katalog danych aplikacji jest poniżej /data/data, a w przypadku Usług Play - tak /data/data/com.google.android.gms.

Pamiętaj, że nie możesz po prostu skopiować go i wkleić w dowolnym miejscu. Aby zajrzeć do katalogu danych aplikacji, potrzebujesz dostępu do konta root. Na szczęście w przypadku urządzeń innych niż root usługi Play pozwalają na tworzenie kopii zapasowych przy użyciu adb .

Po zainstalowaniu ADB wpisz to polecenie w powłoce:

adb backup -apk com.google.android.gms

Spowoduje to zapisanie kopii zapasowej w pliku backup.abznajdującym się w bieżącym katalogu.

Aby przywrócić kopię zapasową, wprowadź to polecenie z tego samego bieżącego katalogu:

adb restore backup.ab

Czy mogę bezpiecznie usunąć dane usług Google Play i pozwolić aplikacji na ich ponowne utworzenie?

Bezpiecznie, jeśli masz na myśli czyszczenie danych z Ustawienia → Aplikacje → Pobrane → Usługi Google Play , to możesz zacząć.

W Androidzie 4.4.2 i 5.0.2 nie ma prostej opcji o nazwie Wyczyść dane . Zamiast tego dostajesz Zarządzaj przestrzenią . Postępuj zgodnie ze zrzutami ekranu:

_{(Kliknij obraz, aby powiększyć; najedź, aby poznać szczegóły)}

Jednak w Androidzie 4.2.1 nie było opcji Zarządzaj przestrzenią, ale Wyczyść dane . Być może ta pierwsza opcja dotyczy wersji Androida, a nie aplikacji.

Robi adb shell pm clear com.google.android.gmsto również bezpieczne, przynajmniej mój Sklep Play i Gmail (zarówno śmiesznie zależny w Play Services) działało w porządku po wykonaniu oba etapy niezależnie.

Dane również zostały odtworzone.

Co mogę stracić, jeśli nieumyślnie usunę dane usług Google Play?

Nie wiem, co nieoczekiwanie oznaczałoby tutaj inne niż wyczyszczenie katalogu aplikacji usług Play bez odinstalowania, więc nie mogę tego komentować.

W każdym razie interfejs usług Play nosi nazwę Ustawienia Google , rdzeń Google Apps , którego ikonę zobaczysz w szufladzie aplikacji. Po prostu otwórz go, a wpisy, które zobaczysz, prawdopodobnie odpowiadają za gromadzenie danych usług Play. I jak powiedziałem powyżej, zależne aplikacje działały dobrze bez żadnych problemów, więc dane tej aplikacji nie są czymś, o co bym się martwił. Twoja sprawa może się różnić, więc zagłęb się w GUI tej aplikacji.

— Firelord
źródło

Zgrabna odpowiedź, dzięki! I zaraz , w twoim przypadku usługi Google Play nie ma miejsca-chciwy w ogóle.

— Bezpłatne konsultacje

Być może dzieje się tak dlatego, że nie używam go zbyt często, poza tym, że czasami pobieram aplikację ze Sklepu Play lub korzystam z Gmaila. W moich innych urządzeniach dane wzrosły do 50 MB. Twój jest szczególnym przypadkiem, ponieważ zarówno dane, jak i pakiet APK zajmowałyby ~ 200 MB pamięci wewnętrznej.

— Firelord

Chociaż to nie to samo, myślę, że muszę to zachować ostrożność ze względu na podobieństwo: PSA: Nie usuwaj danych dla Google Service Framework (Reddit)

— Andrew T.