Status Update
Comments
co...@gmail.com <co...@gmail.com> #2
Hi Sunkesula, which coroutine scope did you use?
[Deleted User] <[Deleted User]> #3
If you use a lifecycle scope then the operation is expected to automatically cancel upon the destroy of the lifecycle owner (e.g. activity lifecycle scope cancels upon activity destroyed by configuration changes).
You need a different scope (e.g. view model scope) to survive across activity lifecycles. Meanwhile, the CredentialManager api takes in an activity: please do not cache that activity into your view model to use view model scope as that can cause memory leak when the activity gets destroyed. Instead, you would want to dynamically get your activity from a callback at the time of the invocation.
kl...@google.com <kl...@google.com> #4
Well, it doesn't help. Even worse. I changed scope to viewModelScope that is created within activity and problem is still there - all the dobbling stuff. If I pass biometry then it crashes with : java.lang.IllegalStateException: Already resumed, but proposed with update CompletedExceptionally[androidx.credentials.exceptions.GetCredentialCancellationException: androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController activity is cancelled by the user.] at kotlinx.coroutines.CancellableContinuationImpl.alreadyResumedError(CancellableContinuationImpl.kt:482)
lu...@gmail.com <lu...@gmail.com> #5
Could you share the code snippet of the scope creation and the call invocation?
ba...@gmail.com <ba...@gmail.com> #6
class LoginFragment : Fragment() {
private val loginViewModel: LoginViewModel by lazy(LazyThreadSafetyMode.NONE) {
ViewModelProvider(this).get(LoginViewModel::class.java)
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
view.findViewById<Button>(R.id.button).setOnClickListener {
loginViewModel.doLogin(requireActivity())
}
}
}
class LoginViewModel : ViewModel() {
fun doLogin(activity: Activity) {
val requestJson = """{"challenge":"SDRfcnFXM2hhMGFvdXNRcFJKcXFZQQ","timeout":120000,"rpId":"dev.ownid.com","userVerification":"required","allowCredentials":["q6g-h9toC9NtisDkWXfAFg"]}"""
viewModelScope.launch {
try {
val getRequest = GetCredentialRequest(listOf(GetPublicKeyCredentialOption(requestJson)))
val result = CredentialManager.create(activity).getCredential(getRequest, activity)
handleSignIn(result)
} catch (e: GetCredentialException) {
handleFailure(e)
}
}
}
}
On button click getting passkey selection dialog (see first png).
Next rotate device and you get two of them - one on top another (see second png).
Complete the top passkey request (no result from getCredential())
Close the bottom dialog (getting successful result from getCredential()).
Instantly app crashes as we get error on main thread:
java.lang.IllegalStateException: Already resumed, but proposed with update CompletedExceptionally[androidx.credentials.exceptions.GetCredentialCancellationException: androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController activity is cancelled by the user.]
at kotlinx.coroutines.CancellableContinuationImpl.alreadyResumedError(CancellableContinuationImpl.kt:482)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl(CancellableContinuationImpl.kt:447)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default(CancellableContinuationImpl.kt:420)
at kotlinx.coroutines.CancellableContinuationImpl.resumeWith(CancellableContinuationImpl.kt:328)
at androidx.credentials.CredentialManager$getCredential$2$callback$1.onError(CredentialManager.kt:121)
at androidx.credentials.CredentialManager$getCredential$2$callback$1.onError(CredentialManager.kt:114)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$handleResponse$2.invoke$lambda$0(CredentialProviderBeginSignInController.kt:140)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$handleResponse$2.$r8$lambda$WczJB-r-nGpR5_auZ66rHEEZm7Y(Unknown Source:0)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$handleResponse$2$$ExternalSyntheticLambda0.run(Unknown Source:4)
at androidx.credentials.CredentialManager$$ExternalSyntheticLambda0.execute(Unknown Source:0)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$handleResponse$2.invoke(CredentialProviderBeginSignInController.kt:139)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$handleResponse$2.invoke(CredentialProviderBeginSignInController.kt:137)
at androidx.credentials.playservices.controllers.CredentialProviderController$Companion$maybeReportErrorResultCodeGet$1.invoke(CredentialProviderController.kt:116)
at androidx.credentials.playservices.controllers.CredentialProviderController$Companion$maybeReportErrorResultCodeGet$1.invoke(CredentialProviderController.kt:116)
at androidx.credentials.playservices.controllers.CredentialProviderController$Companion.cancelOrCallbackExceptionOrResult(CredentialProviderController.kt:134)
at androidx.credentials.playservices.controllers.CredentialProviderController.cancelOrCallbackExceptionOrResult(Unknown Source:2)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController.access$cancelOrCallbackExceptionOrResult$s895630660(CredentialProviderBeginSignInController.kt:57)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$handleResponse$1.invoke(CredentialProviderBeginSignInController.kt:138)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$handleResponse$1.invoke(CredentialProviderBeginSignInController.kt:137)
at androidx.credentials.playservices.controllers.CredentialProviderController$Companion.maybeReportErrorResultCodeGet(CredentialProviderController.kt:116)
at androidx.credentials.playservices.controllers.CredentialProviderController.maybeReportErrorResultCodeGet(Unknown Source:7)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController.handleResponse$credentials_play_services_auth_release(CredentialProviderBeginSignInController.kt:137)
at androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$resultReceiver$1.onReceiveResult(CredentialProviderBeginSignInController.kt:100)
at android.os.ResultReceiver$MyRunnable.run(ResultReceiver.java:50)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7884)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
ba...@gmail.com <ba...@gmail.com> #7
Maybe it helps. LeakCanary indicates leak after screen rotation:
┬───
│ GC Root: Global variable in native code
│
├─ android.os.ResultReceiver$MyResultReceiver instance
│ Leaking: UNKNOWN
│ Retaining 274.0 kB in 5254 objects
│ ↓ ResultReceiver$MyResultReceiver.this$0
│ ~~~~~~
├─ androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$resultReceiver$1
│ instance
│ Leaking: UNKNOWN
│ Retaining 273.5 kB in 5253 objects
│ Anonymous subclass of android.os.ResultReceiver
│ ↓ CredentialProviderBeginSignInController$resultReceiver$1.this$0
│ ~~~~~~
├─ androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController instance
│ Leaking: UNKNOWN
│ Retaining 273.5 kB in 5251 objects
│ activity instance of com.ownid.demo.firebase.ui.activity.MainActivity with mDestroyed = true
│ ↓ CredentialProviderBeginSignInController.activity
│ ~~~~~~~~
╰→ com.ownid.demo.firebase.ui.activity.MainActivity instance
Leaking: YES (ObjectWatcher was watching this because com.ownid.demo.firebase.ui.activity.MainActivity received
Activity#onDestroy() callback and Activity#mDestroyed is true)
Retaining 273.1 kB in 5238 objects
key = 1c3d91c7-c738-4bc5-8dba-95247ac05760
watchDurationMillis = 41713
retainedDurationMillis = 36712
mApplication instance of com.ownid.demo.firebase.DemoApp
mBase instance of androidx.appcompat.view.ContextThemeWrapper
====================================
[Deleted User] <[Deleted User]> #8
Thank you for your help @dimitriy@ownid.com. You are right in that we don’t properly handle the configuration changes. Thank you for identifying this bug. What our upcoming changes can do is consistently ensure that upon rotation, our system stays consistent. I think the expected behavior here should depend upon the app - so possibly but not necessarily always will there be a cancellation. At the moment, the 'cancellation' will look strange, but is effectively doing a cancellation.
However, the application that our system runs on must also account for a configuration change. This can be done by matching the configuration consistency shown
<activity
android:name=".ExampleMainActivity"
android:configChanges="keyboardHidden|orientation|screenSize" // This line
......>
If the underlying application does not account for the configuration change, then the expected response will never make it to the designated receiver, because the underlying application is no longer in the same state as our system. Thus, the bottom sheet will remain up, but the credentials will land no-where when clicked or closed. It is, effectively, ‘canceled’, but it will look strange.
This may be worth following up so that both cases are handled (ensuring those who have set the most widely used configuration changes still get a consistent experience and ensure those who do not get a complete cancellation rather than the strange 'UI-still-up' version that exists today). However, for now, the former is the targeted solution and hopefully it can help avoid the strange behavior you experienced once the next version is released.
bo...@gmail.com <bo...@gmail.com> #9
The videos below showcase the now expected behaviour. The 'AppConfigured' assumes the underlying app is properly configured to handle these core changes. The 'NonConfiguredDefaultCanceled' shows the 'UI-still-up' version of cancellation. In all cases, the repeating bottom-sheets have been fixed, and in the case when the underlying app is properly configured, the final credential is properly returned to the application as expected.
mi...@gmail.com <mi...@gmail.com> #10
Branch: androidx-main
commit f34fe3a42b515adafe4d50841df9ae6a1b836c06
Author: Arpan Kaphle <akaphle@google.com>
Date: Wed Apr 05 21:36:35 2023
Fixing Hidden Activity Configuration Change Issue
From external users, there was un-intentional and un-intended behaviour
of the play auth module during configuration changes, namely rotation.
This provides a fix, which was tested. However, this fix only ensures no
duplicate bottom sheets from play auth. Users who utilize this must also
make the corresponding change to their applications. Otherwise, the
application state will re-start their activity, and will cause the play
auth bottom sheet to be effectively 'canceled', but still appear 'up'.
This behaviour could be further examined and a plan setup to avoid the
strange looking canceled.
Bug: 276939495
Bug: 276316128
Test: Tested on Device and Built
Change-Id: Ie8a6c0db52b98766274c15dc424f4485f79128d3
M credentials/credentials-play-services-auth/src/main/AndroidManifest.xml
mi...@gmail.com <mi...@gmail.com> #11
Thanks for reply. I see the proposed changes as a temporal workaround and not as proper library behavior on configuration changes. Even more - the proposed changes "fix" only some cases for configuration changes, not all of them.
In addition to that, proposed fix requires changes to be introduced to the customers application, in particular how activity handles configurations changes. This may not be acceptable way to fix the issue, especially in my case as SDK developer. I cannot ask customer to do such changes as it may break many things in there production app.
Bottom line - proposed solution does not solve the problem.
co...@gmail.com <co...@gmail.com> #12
lu...@gmail.com <lu...@gmail.com> #13
wa...@gmail.com <wa...@gmail.com> #14
Ok
[Deleted User] <[Deleted User]> #15
F
gd...@gmail.com <gd...@gmail.com> #16
ha...@google.com <ha...@google.com> #17
el...@gmail.com <el...@gmail.com> #18
Branch: androidx-main
commit a75fcac0d319a411a6d750119b9ac2e0f3585a7c
Author: Arpan Kaphle <akaphle@google.com>
Date: Mon Apr 10 20:56:24 2023
Configuration Change Consistency in Play Auth Flow
This change is a follow up to a prior change that handles more general
configuration changes - or really anything that restarts the app
(assuming it is run in the proper scope, namely a non cancellation
inducing scope in the programming). This ensures that the behaviour of the underlying
module is consistent and returns credentials as expected.
Bug: 276316128
Bug: 276939495
Test: E2E Test and Build
Change-Id: Iae8ce99fa56d237d874c5af2c61a914aaaeb85e4
M credentials/credentials-play-services-auth/src/main/java/androidx/credentials/playservices/HiddenActivity.kt
M credentials/credentials-play-services-auth/src/main/java/androidx/credentials/playservices/controllers/CredentialProviderBaseController.kt
M credentials/credentials-play-services-auth/src/main/java/androidx/credentials/playservices/controllers/CredentialProviderController.kt
ga...@gmail.com <ga...@gmail.com> #19
I hope you can excuse me for the delayed response. We have put up a new solution that should contain the expected behavior. If the calling application uses a cancellable scope as @helenqin@google.com mentioned above, a proper JobCancellationException will be thrown. If a non cancellable scope is used, even on configuration change, our library will ensure proper return of credentials. You can expect this change to arrive in the next release, around May.
In the meantime, to try this out you can use a snapshot SDK from
Step 1: Add the following maven url line to your build.gradle file.
allprojects {
repositories {
google()
jcenter()
maven { url 'https://androidx.dev/snapshots/builds/9928302/artifacts/repository' }
}
}
Step 2: Depend on the snapshot version artifact:
dependencies {
def work_version = '1.0.0-SNAPSHOT'
implementation "androidx.credentials:credentials-play-services-auth:$work_version"
...
}
Thank you for your patience, and please let us know if there are any other issues. We appreciate your help in making Credential Manager better prior to the final launch.
ng...@gmail.com <ng...@gmail.com> #20
I confirm that issue is fixed. Thanks! However memory leak is still present. Will open another issue for that.
st...@gmail.com <st...@gmail.com> #21
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.credentials:credentials-play-services-auth:1.0.0-alpha07
jp...@gmail.com <jp...@gmail.com> #22
When I call getCredential() and the identity selection pops up, I select an account and the popover cancels, and then nothing
The code:
fun Login(mActivity:Activity,mCredentialManager: CredentialManager,mGoogleIdOption: GetGoogleIdOption){
viewModelScope.launch {
try {
val request: GetCredentialRequest = GetCredentialRequest.Builder()
.addCredentialOption(mGoogleIdOption)
.build()
val result = mCredentialManager.getCredential(mActivity,request)
if (result != null) {
handleSignIn(result)
} else {
}
} catch (e: GetCredentialException) {
Log.e(LoginActivity.TAG, e.toJson())
}
}
}
Error: {"errorMessage":"activity is cancelled by the user.","type":"android.credentials.GetCredentialException. TYPE_USER_CANCELED","detailMessage":"activity is cancelled by the user.","stackTrace":[]}
Configured version: implementation "com.google.android.libraries.identity.googleid:googleid:1.1.0"
implementation("androidx.credentials:credentials:1.3.0-alpha01")
implementation("androidx.credentials:credentials-play-services-auth:1.3.0-alpha01”)
pr...@gmail.com <pr...@gmail.com> #23
de...@gmail.com <de...@gmail.com> #24
This looks like a different issue, could you please open a new bug with more details about which version of jetpack you're using, which version of android you're running, a bug report and etc.
or...@gmail.com <or...@gmail.com> #25
er...@gmail.com <er...@gmail.com> #26
el...@gmail.com <el...@gmail.com> #27
vs...@google.com <vs...@google.com> #28
ni...@gmail.com <ni...@gmail.com> #29
ry...@bissell.org <ry...@bissell.org> #30
For NDK r9:
Find this line in ndk-gdb:
run adb_cmd shell run-as $PACKAGE_NAME lib/gdbserver +$DEBUG_SOCKET --attach $PID &
replace it with these 4 lines (assuming you have $NDK defined, and assuming your target device is ARM):
run adb_cmd forward tcp:5039 tcp:5039
run adb_cmd remount
run adb_cmd push $NDK/prebuilt/android-arm/gdbserver /system/bin/gdbserver.temp
run adb_cmd shell /system/bin/gdbserver.temp --attach :5039 $PID &
I am working from memory above, didn't actually test exactly what I've written just now, so I apologize for any mistakes, but that is the general idea.
Again, this requires rooted device.
pa...@gmail.com <pa...@gmail.com> #31
ni...@gmail.com <ni...@gmail.com> #32
cl...@gmail.com <cl...@gmail.com> #33
*Do not forget to add NDK_DEBUG=1...
gd...@gmail.com <gd...@gmail.com> #34
kl...@google.com <kl...@google.com>
nn...@google.com <nn...@google.com>
eo...@gmail.com <eo...@gmail.com> #36
nn...@google.com <nn...@google.com> #37
eo...@gmail.com <eo...@gmail.com> #38
bo...@gmail.com <bo...@gmail.com> #39
jo...@gmail.com <jo...@gmail.com> #40
1. remount /system rw
2. chmod 4750 /system/bin/run-as
3. remount /system ro
4. enjoy debugging native code
jo...@gmail.com <jo...@gmail.com> #41
jo...@gmail.com <jo...@gmail.com> #42
bi...@gmail.com <bi...@gmail.com> #43
I had a hard time figuring out how to run those commands. I tinkered around and finally got it.
For rooted devices running a custom recovery:
- reboot to recovery
- find the mount system and check it
- open a terminal and type: adb shell
- type: chmod 4750 /system/bin/run-as
- uncheck the System mount and reboot!
ze...@gmail.com <ze...@gmail.com> #44
anyone has any idea on how to fix that?
ti...@gmail.com <ti...@gmail.com> #45
ze...@gmail.com <ze...@gmail.com> #46
ze...@gmail.com <ze...@gmail.com> #47
eo...@gmail.com <eo...@gmail.com> #48
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:5039
Error message from debugger back end:
Remote communication error. Target disconnected.: No error.
Remote communication error. Target disconnected.: No error.
jo...@gmail.com <jo...@gmail.com> #49
BTW. I've confirmed that flashing the factory image works as a workaround for this issue too. It's probably the preferred method to using the steps I put in #41.
nn...@google.com <nn...@google.com> #50
jo...@gmail.com <jo...@gmail.com> #52
m8...@gmail.com <m8...@gmail.com> #53
nn...@google.com <nn...@google.com> #54
kl...@gmail.com <kl...@gmail.com> #55
In my case update to 4.4.2
ki...@gmail.com <ki...@gmail.com> #56
I currently have 4.4.2 OTA upgraded and I can't run adb gdb.
nn...@google.com <nn...@google.com> #57
If you can't run gdb, you should file a new bug. It's likely unrelated to this issue.
gi...@gmail.com <gi...@gmail.com> #58
sl...@gmail.com <sl...@gmail.com> #59
So I decided to share my one week hell with OTHER developers.
The reason behind all this are definitely permissions to directories and files in kernel.
So for this fix to work you really need to have rooted device to change permissions on folders and files.
1) You have to change permissions on run-as file in /system/bin folder by following these commands
adb -s <your device id> shell
su
mount -o rw,remount /system
chmod 4750 /system/bin/run-as
mount -o ro,remount /system
In the end run-as has rwsr-x--- permissions, owner is root, group is shell
2) Make sure /data folder has rwxrwx--x permissions, owner system, group system
3) Make sure /data/data folder has rwxrwx--x permissions, owner system, group system
4) Make sure /data/data/<packagename> folder has rwxrwx--x permissions, owner is uid from packages.list, group is uid from packages.list
In my case I did not have to change any permissions to packages.list file because run-as temporarily switches effective GID to allow read the packages file and also
8Kb is not the case, because run-as reads all the lines from packages.list until it finds package provided by arguments.
example from my packages.list
com.example.native_activity 10234 1 /data/data/com.example.native_activity default
package name: com.example.native_activity
uid: 10234
debuggable: 1
directory path: /data/data/com.example.native_activity
some info: default
uid is used for checking user permissions on /data/data/com.example.native_activity directory
I hope these steps help others too.
ab...@gmail.com <ab...@gmail.com> #60
Has the issue reappeared?
bo...@gmail.com <bo...@gmail.com> #61
I am also seeing this issue on Samsung Galaxy S4 with both Android 4.3 and Android 4.4.2. If anybody can find an appropriate Samsung-specific issue tracking location for this issue, please do link to it here!
bo...@gmail.com <bo...@gmail.com> #63
bo...@gmail.com <bo...@gmail.com> #64
So this issue appears to have resolved in Android 4.4.2 on Samsung devices, as well as on Nexus devices.
ki...@gmail.com <ki...@gmail.com> #65
I was experiencing the issue even though my phone was updated to 4.4.2 months ago. This was particularly aggravating because everywhere I looked, I would find other people celebrating the fact that the 4.4.2 update fixed everything for them.
It turns out reinstalling 4.4.2 and wiping all data on the phone is the answer, but you can't just do that from the recovery image already present on the phone; the bug will just remain.
I had to download a dump of the exact version of 4.4.2 used by my mobile provider for my phone model from some shady website (same exact build number / baseband version / ISP code), and flash it from Download mode. Then, when I rebooted and reinstalled, native debugging simply worked.
So, just to be clear, for some reason, if you HAD a bugged version before and you updated to 4.4.2 through your mobile provider ("OTA"), it's possibly still affected by this particular issue, and the only way to fix it is to reflash -- the procedure is the same as a downgrade.
ss...@gmail.com <ss...@gmail.com> #66
ki...@gmail.com <ki...@gmail.com> #67
ss...@gmail.com <ss...@gmail.com> #68
ki...@gmail.com <ki...@gmail.com> #69
ss...@gmail.com <ss...@gmail.com> #70
vi...@gmail.com <vi...@gmail.com> #71
ba...@gmail.com <ba...@gmail.com> #72
Google fixed it months ago.
vi...@gmail.com <vi...@gmail.com> #73
vi...@gmail.com <vi...@gmail.com> #74
co...@gmail.com <co...@gmail.com> #75
kr...@gmail.com <kr...@gmail.com> #76
On reading this thread, i thought it was due to the OTA update and so installed the factory OS from
But even after doing this, it didn't work. The permissions for package.list are still bad.
1|shell@mako:/ $ ls -al /data/system/packages.list
-rw-rw---- system package_info 13286 2014-05-26 19:15 packages.list
Can anyone point out what am i doing wrong?
vh...@google.com <vh...@google.com> #77
problem.
I would build 4.4.2 from source and flash it onto your device.
after update to 4.3
installed the factory OS from
instructions for installing the factory image were taken from
package.list are still bad.
ki...@gmail.com <ki...@gmail.com> #78
This is normal -- apps are not supposed to be able to read packages.list anymore, and that shouldn't interfere with run-as.
Note that this issue is characterized by the error message "run-as: Package '...' is unknown." If you don't get that particular message, the issue might be different.
The message can also pop-up if you forget to set the "android:debuggable" flag in the manifest -- see
kr...@gmail.com <kr...@gmail.com> #79
[2014-05-27 12:00:54 - ImageCoreTest] Unable to find a compatible ABI
[2014-05-27 12:00:54 - ImageCoreTest] ABI's supported by the application: x86
[2014-05-27 12:00:54 - ImageCoreTest] ABI's supported by the device: armeabi-v7a, armeabi
This was not correct as when i run the same app, it works fine. The Application.mk file had
APP_ABI := armeabi-v7a
Please note, we also build X86 binary for faster debugging in android emulator.
However when i put "APP_ABI := armeabi-v7a" in Android.mk file, i can debug. This is not where it is supposed to be according to android docs but it works :(
Also, when we put "android:debuggable" in manifest, it gives an error that it should not be hardcoded. Even without it, debugging it working fine.
ci...@gmail.com <ci...@gmail.com> #80
ci...@gmail.com <ci...@gmail.com> #81
Thanks.
jm...@gmail.com <jm...@gmail.com> #84
nn...@google.com <nn...@google.com> #85
ad...@gmail.com <ad...@gmail.com> #86
ad...@gmail.com <ad...@gmail.com> #87
cr...@gmail.com <cr...@gmail.com> #88
I know this problem and even don't want to upgrade system,
but today I just carelessly touched the update button.
Samsung Galaxy S6 upgraded from 5.0 to 5.1.1 and damn!
eh...@gmail.com <eh...@gmail.com> #89
vh...@google.com <vh...@google.com> #90
This issue is closed. If you are currently having issues, please file a new bug.
Description
Best regards,
Dmitry