Problemy z logowaniem w Usługach gier Google Play

Question

Wdrażam usługę gier Google Play w mojej grze, aby zapewnić funkcję gier w czasie rzeczywistym dla wielu graczy (przy użyciu libgdx i BaseGameUtils).

Wszystko działa poprawnie na moim Nexusie 4 z moim głównym kontem Google (Zaloguj się, tworząc pokój itp.), Nazwij go "A".

Aby przetestować zautomatyzowanie i wysłanie/odebranie wiadomości, utworzyłem drugie konto Google, nazwać je "B" i dodałem to konto do mojej (fabrycznie zresetowanej) karty Samsung Galaxy.

Na początku wszystko działało również dobrze - udało mi się stworzyć automatyczny pokój, wysyłać i odbierać wiadomości tekstowe, itp. Ale po 15 minutach testów nie mogłem już się zalogować z kontem "B" na Karta Galaxy. Konto "A" na Nexusie 4 nadal działa poprawnie.

Aby wykluczyć jakiekolwiek problemy z urządzeniem, dodałem konto "A" do zakładki Galaxy i logowanie przebiegło pomyślnie. Dodałem także konto "B" do mojego Nexusa 4, a logowanie nie działa.

Po odczekaniu pewnego czasu (30 minut), nazwa logowania z konta "B" znowu działa na obu urządzeniach. I to jest mój obecny stan: mogę zrobić kilka testów z kontem "B", ale po krótkim czasie dostaję "zablokowany" i muszę poczekać, aż będę mógł go ponownie użyć. Konto "A" działa zawsze.

Podczas tego "blokowania" czasu, próbowałem wszystkiego: usuwanie danych aplikacji/pamięci podręcznej, usuwanie danych usługi odtwarzania/pamięci podręcznej, odłączanie aplikacji z moim kontem "B". Nic nie działa. Oto wyjście logcat, jeśli chcę się zalogować na konto „B”, a to jest „zablokowany”:

07-27 13:20:35.508: I/dul(13742): I/O exception (org.apache.http.NoHttpResponseException) caught when processing request: The target server failed to respond 
07-27 13:20:35.508: I/dul(13742): Retrying request 
07-27 13:20:35.808: E/Volley(13742): [1224] ip.a: Unexpected response code 403 for https://www.googleapis.com/games/v1/players/102515671693140579145 
07-27 13:20:35.818: E/SignInIntentService(13742): Access Not Configured 
07-27 13:20:35.818: E/SignInIntentService(13742): ark 
07-27 13:20:35.818: E/SignInIntentService(13742): at ams.b(SourceFile:189) 
07-27 13:20:35.818: E/SignInIntentService(13742): at ams.a(SourceFile:111) 
07-27 13:20:35.818: E/SignInIntentService(13742): at adz.a(SourceFile:220) 
07-27 13:20:35.818: E/SignInIntentService(13742): at adz.a(SourceFile:201) 
07-27 13:20:35.818: E/SignInIntentService(13742): at adi.a(SourceFile:489) 
07-27 13:20:35.818: E/SignInIntentService(13742): at att.a(SourceFile:221) 
07-27 13:20:35.818: E/SignInIntentService(13742): at com.google.android.gms.games.service.GamesSignInIntentService.onHandleIntent(SourceFile:343) 
07-27 13:20:35.818: E/SignInIntentService(13742): at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65) 
07-27 13:20:35.818: E/SignInIntentService(13742): at android.os.Handler.dispatchMessage(Handler.java:99) 
07-27 13:20:35.818: E/SignInIntentService(13742): at android.os.Looper.loop(Looper.java:137) 
07-27 13:20:35.818: E/SignInIntentService(13742): at android.os.HandlerThread.run(HandlerThread.java:60) 
07-27 13:20:35.818: E/LoadSelfFragment(16159): Unable to sign in - application does not have a registered client ID 

Oczywiście mam zarejestrowany identyfikator klienta, inaczej nie mogę się zalogować z konta " "A czasem z kontem" B ". Oczywiście dodałem oba konta w konsoli programisty do białej listy testowej. I oczywiście dodałem prawidłowy identyfikator aplikacji poprzez link do mojego manifestu.

Nie sądzę, że ma to coś wspólnego z moim kodem, ponieważ konto A nigdy nie ma problemów, a konto B działa "czasami". Czy są jakieś znane problemy z białą listą testową? Czy masz jakieś sugestie, jak rozwiązać ten problem? Przy okazji nie sądzę, że mam ograniczoną liczbę stanowisk, ponieważ wpłynęłoby to na oba konta, prawda?

Bardzo dziękuję za pomoc

Answer 1

Niedawno zacząłem mieć również te problemy. Myślę, że mogą wykonywać pewne czynności konserwatorskie po swojej stronie. Właśnie zacząłem używać innego konta testowego i wszystko zaczęło działać. Oczywiście mam teraz inne problemy. Zajmuję się moim problemem i będę aktualizować, gdy znajdę anwers. Na razie proponuję po prostu użyć innego (lub nowego) konta testowego (i pamiętaj, aby pamiętać o autoryzacji konta do przetestowania w konsoli programisty!).

Answer 2

Mam dokładnie ten sam problem co użytkownik2446468, niektóre z moje konto testowe nie zaloguje się po kilkugodzinnej pracy (po tej początkowej awarii będą działać dopiero po pół godzinie ...)

Oto mój Dziennik dla tego wydarzenia ...

08-06 17:03:08.945: D/Volley(21844): [664] ip.a: HTTP response for request=<[ ] https://www.googleapis.com/games/v1whitelisted/applications?language=en_US&platformType=ANDROID NORMAL 20> [lifetime=5926], [size=531], [rc=200], [retryCount=0] 
08-06 17:03:08.975: D/Volley(21844): [1] ia.b: 5956 ms: [ ] https://www.googleapis.com/games/v1whitelisted/applications?language=en_US&platformType=ANDROID NORMAL 20 
08-06 17:03:09.075: I/dul(21844): I/O exception (org.apache.http.NoHttpResponseException) caught when processing request: The target server failed to respond 
08-06 17:03:09.075: I/dul(21844): Retrying request 
08-06 17:03:09.295: W/AlarmManager(2301): FACTORY_ON= 0 
08-06 17:03:09.915: E/Volley(21844): [655] ip.a: Unexpected response code 403 for https://www.googleapis.com/games/v1/players/11******************* 
08-06 17:03:09.950: E/SignInIntentService(21844): Access Not Configured 
08-06 17:03:09.950: E/SignInIntentService(21844): ark 
08-06 17:03:09.950: E/SignInIntentService(21844): at ams.b(SourceFile:189) 
08-06 17:03:09.950: E/SignInIntentService(21844): at ams.a(SourceFile:111) 
08-06 17:03:09.950: E/SignInIntentService(21844): at adz.a(SourceFile:220) 
08-06 17:03:09.950: E/SignInIntentService(21844): at adz.a(SourceFile:201) 
08-06 17:03:09.950: E/SignInIntentService(21844): at adi.a(SourceFile:489) 
08-06 17:03:09.950: E/SignInIntentService(21844): at att.a(SourceFile:221) 
08-06 17:03:09.950: E/SignInIntentService(21844): at com.google.android.gms.games.service.GamesSignInIntentService.onHandleIntent(SourceFile:343) 
08-06 17:03:09.950: E/SignInIntentService(21844): at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65) 
08-06 17:03:09.950: E/SignInIntentService(21844): at android.os.Handler.dispatchMessage(Handler.java:99) 
08-06 17:03:09.950: E/SignInIntentService(21844): at android.os.Looper.loop(Looper.java:137) 
08-06 17:03:09.950: E/SignInIntentService(21844): at android.os.HandlerThread.run(HandlerThread.java:60) 
08-06 17:03:09.965: E/LoadSelfFragment(7796): Unable to sign in - application does not have a registered client ID 

UPDATE: mam silne powody, aby wierzyć, że naprawdę jest coś „blokowanie” znak-w przez okres czasu (Zrobiłem kilka testów, opracowano wersję stres-test, który stale próbować logowanie (z bardzo rozsądnym czasem odnowienia 10sec, aby nie osiągnąć żadnego z limitów żądań), jeśli logowanie się nie powiodło ... Wynikiem było około 30-45 minut okresu offline i pełne odzyskanie po tym czasie (bez interwencji użytkownika) ... mam następujące teorie:

• Nie może być inaczej przymusowe kontyngenty na nieopublikowanych aplikacji :(
• To może być błąd po stronie serwera, gdy Google próbuje uwierzytelnić, jeśli użytkownik rzeczywiście znajduje się na liście testerów dla nieopublikowanej aplikacji (wszyscy odwiedzający go w pobliżu, aby to sprawdzić u nas?)
• To samo, co powyżej, ale dla niepublikowanych sama aplikacja (ale wątpię w to, ponieważ możliwe jest zalogowanie się z użytkownikiem A, a nie użytkownikiem B w danym momencie).
• Może być wbudowana pamięć podręczna w lokalnej usłudze usług gier (buforowanie nieprawidłowego identyfikatora klienta (może gdzieś gdzieś null) do APP i tym samym otrzymanie błędu 403), jeśli tak, to jest błąd w samym API Play Game Services, a nie po stronie serwera ...

Czy powinienem coś odkryć? Będę was informował. ..

Answer 3

Takie zachowanie będzie występować, jeżeli:

Bieżący użytkownik jest podłączony do każdego pomieszczenia oraz:

aplikacja zostaje wznowiona tak, że próbuje się zalogować do usługi Google bez przeszedł jako odłączenie części wymagane przez Usługi Google Play.

Znalazłem to dość regularnie (niestety dla mnie), ponieważ zastanawiałem się, jak przekazać wiadomości między moim kodem Android i stroną kodową LibGDX (moja aplikacja po prostu się zablokuje z powodu problemów z synchronizacją). Ustawiam także kilka kont testowych, które mogę "przełączyć", aby uniknąć całkowitego zablokowania logowania. Jednak okazało się, że jeśli użyłem Menedżera zadań do zabicia procesu przed ponownym uruchomieniem aplikacji, 90+ procent czasu, Mogę nadal używać tego samego konta.

Jeśli aktualizujesz swój kod i ładujesz go do urządzenia podczas przebywania w pokoju, spowoduje to również gniew serwera na około 30 minut dla tego konta.

W skrócie, aby zachować swoje konto opłacalne:

1) zapewnić LeaveRoom przed aktualizację kodu (Znalazłem wylogowaniu PS nie jest wymagane) 2) Jeśli aplikacja zamki w górę ... Zabicie procesu za pomocą Menedżera zadań (używam Samsunga) najprawdopodobniej pozwoli na kontynuowanie Twojego konta (możesz zobaczyć w logcat, gdzie wywołuje rozłączenie, gdy to zrobisz) po ponownym uruchomieniu aplikacji.

Answer 4

Czy masz konto testowe dodane do obu urządzeń (poprzez Ustawienia)?

Wiem, że to głupie pytanie, ale miałem swoje konto testowe tylko na jednym urządzeniu i otrzymałem ten sam (bardzo niepomocny) komunikat o błędzie. Nie możesz po prostu założyć, że możesz dodać konto testera do drugiego urządzenia za pośrednictwem zwykłego logowania - po prostu zawiedzie, chyba że masz już konto Google na urządzeniu z dostępem testera.