-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signup Failure - prompt to update while Play Services are actually disabled #6381
Comments
|
One might as well treat "gcm too old" the same as "gcm missing". That might enable Signal in the future to run on devices for which no newer gcm becomes available. |
|
My hypothesis is that the googely bit that checks for the status of the Play Services returns "Update needed" when they are both outdated and disabled. (A quick dirty tip on how to circumvent this locally on my device would be nice, in case this won't ne implemented soon.) |
|
I think you'll have to file this bug with Google |
|
Android 6.0, Google Play Services disabled. |
|
@moxie0 |
|
Because no matter who's fault this is, this bug prevents usage of Signal under the described circumstances. That's a pity. |
|
Another point to consider: As far as I can see, if we want this to be fixed, we need to make a change to Signal itself (multiple options are mentioned in the comments above). [Sorry for my the many words, I greatly appreciate the work everybody is doing here.] |
|
The bug would be in the stub that's linked into Signal, not the GMS service on the device. |
|
So I did some research but failed to find the correct place for reporting bugs against the Google Play Services "Client Library" (thats what the stub is called). [Following @johanw666 's suggestion I created a branch where outdated Services would result in a promptForNoPlayServices. |
|
It is fairly common that people need to update Play Services, much less so that people have decided to use an Android device without Play Services for ideological or safety reasons, but only marked it disabled rather than removing it. Using Play Services provides a better experience and is more secure, so we would not want to enable defaults that reflect otherwise. However, I would accept a PR that explicitly checks if Play Services has been disabled if the client library reports missing. |
|
@le-bug : AFAIK Play Services only upgrade themselves if there is an active Google account on the device. I'm running stock Android with gcm but I have no Google account activated on my device. I have to download updates for the Play Services from apkmirror. |
|
@moxie0 that's fair. So it looks like other people (http://stackoverflow.com/questions/32220798/how-to-check-google-play-services-is-enabled-disabled-from-code-in-android) have found that disabled+outdated Play Services are considered as outdated. I would still like for that to be reported as a bug. For explicitly checking if Play Services have been disabled I found two ways. They use the android PackageManager. 1st ApplicationInfo ai = getActivity().getPackageManager().getApplicationInfo("com.google.android.gms",0);
boolean appStatus = ai.enabled;should return false for the appStatus if GMS is disabled. Documentation: 2nd. getApplicationEnabledSetting does something similar. So I think one could check this way first and then call the Play Client Library call afterwards, or do this check when the Client Library says NEEDS_UPDATE but before the getErrorDialog part. (I am sorry that I am talking so much about what could be done, but not doing much of the doing. I am not actually a programmer and not sure if me hacking roughly on this would lead to a result that is appropriate for such a security critical application.) |
|
How about instead of an error window asking the user to update play service, pop a dialog asking the user whether they want to update the play service or use signal without it. So instead of one button "update" it is now 2 buttons "update" and "continue without". Just my 2 cents. |
|
So, one walk in the sun and a few explanations from friends later, and I have learned enough java syntax to implement what @moxie0 said he would merge. You can see the results here: I would be very happy to have more eyes on this, so I encourage everyone interested to proofread and test. One thing I am not sure of: |
That link is 404. @le-bug Are you still trying to solve this? |
|
I tried working around this by updating Play Services from apkmirror. Well I got little further, received the sms message but Signal could not reach server. Network error. This happened with wifi and just mobile data. Maybe I'm missing something... |
|
Thank you @moxie0 so much for the fix. [It looks like the release at https://signal.org/android/apk/ lags behind the Google Play one in the version number.] |
I have:
Bug description
I was eager to try out the new non gcm functionality, got an android phone and promptly disabled the Google Play Apps (precise lising below). Trying to sign up for Signal resulted in a failure, as the App requires me for some reason to update the Play Services before continuing. This locks me out.
[I dont think this is wanted behavior.
Looking into src/org/thoughtcrime/securesms/RegistrationActivity.java, it looks like
ConnectionResult.SERVICE_DISABLED
is supposed to be treated as MISSING but that doesn't seem to work.]
Steps to reproduce
Actual result:
A pop up appears:
Update Google Play Services
Signal won't run unless you update Google Play Services.
This is impossible as they are intentionally disabled and unwanted as we want to use Websocket push.
Expected result:
The registration happens and Signal sets up so that gcmdisabled true is set. Signal can be used.
(Treat this as if the Google Play service components were just MISSING)
Device info
Android version: 6.0.1
Signal version: 3.31.4
Stock Rom. Newly of the shelf bought phone.
disabled apps:
com.google.android.gms
com.android.vending
com.google.android.gsf
Debug log not available as signup is impossible.
A fix would be greatly appreaciated, as it would allow to quickly setup an android burner phone for Signal without much technical sophistication.
The text was updated successfully, but these errors were encountered: