Fixed
Status Update
No update yet.
Comments
su...@google.com
he...@google.com
My application offers 'suggested applications' that it can install and then use the functionality of, acting as a plug-in. Tasker is one of those.
My only work-around is to prompt the user to reinstall my application after the suggested applications have been installed, so permissions are detected.
It's of course a horrible 'solution'. Have starred the issue.
brandall
My only work-around is to prompt the user to reinstall my application after the suggested applications have been installed, so permissions are detected.
It's of course a horrible 'solution'. Have starred the issue.
brandall
he...@google.com
dm...@ownid.com
Using the terminology from the original issue report, one workaround is for App A *and* App B to define the same <permission>. This gets a bit dicey in plugin situations, where App A is not written by the author of App B, only because App A would need all relevant resources (e.g., internationalized strings). OTOH, it works.
he...@google.com
This has security implications as well. Consider the following:
---
App HOST allows access to personally-identifying information through a permission.
App PLUGIN can get access to this information by defining the <permission> as well, and using its own permission.
However, if HOST is not already installed, this permission is not shown to the user when PLUGIN is installed.
When HOST is later installed, PLUGIN now has access to HOST's data, even though the user was never aware of it.
---
Perhaps this is a separate bug. The expected behavior is, if an app has a <uses-permission>, that permission should be shown to the user REGARDLESS of whether the permission exists in another app or doesn't.
---
App HOST allows access to personally-identifying information through a permission.
App PLUGIN can get access to this information by defining the <permission> as well, and using its own permission.
However, if HOST is not already installed, this permission is not shown to the user when PLUGIN is installed.
When HOST is later installed, PLUGIN now has access to HOST's data, even though the user was never aware of it.
---
Perhaps this is a separate bug. The expected behavior is, if an app has a <uses-permission>, that permission should be shown to the user REGARDLESS of whether the permission exists in another app or doesn't.
dm...@ownid.com
It doesn't work this way. Permissions are granted at install time *only*, so if you install HOST after PLUGIN, PLUGIN doesn't get any extra permissions. Of course, if they are using sharedUserId you get the union of both sets of permissions, but that's a different story.
dm...@ownid.com
Perhaps it's not meant to work this way, but I just tested and it does. I installed PLUGIN first (which has both <permission> and <uses-permission>), which obviously doesn't work correctly because HOST is not installed. Then I installed HOST (which has the same <permission> defined). PLUGIN now has access to HOST.
he...@google.com
ak...@google.com
#9: However, you were presented with the custom permission at install time of PLUGIN, as you had <uses-permission>. The exception to this is signature-level permissions, which are never presented to the user, as the signature match alone is sufficient.
ak...@google.com
The problem here is that the PLUGIN can have a different description of the permission in its <permission> tag than the HOST.
You could even use descriptions that look like a boring android permission like INTERNET.
You could even use descriptions that look like a boring android permission like INTERNET.
ap...@google.com
@mmurphy: That's the thing - at the time of PLUGIN's install, I did *not* see that permission. Could be my ROM though - running 4.2.2/SlimROM/Galaxy Nexus. Would be good if someone could confirm.
@domschuermann: But yes, different descriptions/icons/names are also a problem, and the solution to this isn't trivial.
@domschuermann: But yes, different descriptions/icons/names are also a problem, and the solution to this isn't trivial.
dm...@ownid.com
Might I add, the permission level was kept at the default, and I signed the two packages with different signatures (one with a debug key, the other with a release).
ah...@gmail.com
Comment has been deleted.
ah...@gmail.com
Comment has been deleted.
ah...@gmail.com
As of Android 5.1, at least, trying to re-define the permission gives an installation error for the second app:
W/PackageManager( 746): Package com.whatever.foo attempting to redeclare permission com.permission.your already owned by com.example.thing
W/PackageManager( 746): Package com.whatever.foo attempting to redeclare permission com.permission.your already owned by com.example.thing
ah...@gmail.com
Is this fixed or affected by Android 6.0 permissions changes?
ah...@gmail.com
Comment has been deleted.
ah...@gmail.com Restricted+
Restricted+
Comment has been deleted.
ap...@google.com
Yes, this is the way permissions work.
Adding moltmann@ if he wants to resurrect this and try to figure out a way to fix this.
Adding moltmann@ if he wants to resurrect this and try to figure out a way to fix this.
ak...@google.com
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 @he...@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.
sg...@google.com
dm...@ownid.com
I confirm that issue is fixed. Thanks! However memory leak is still present. Will open another issue for that.
pr...@google.com
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
gu...@gmail.com
Hello, I also have the same problem, but not because of the landscape portrait.
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”)
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”)
gu...@gmail.com
This is my screen
sg...@google.com
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.
Description
Component used: Credentials
Version used: androidx.credentials:credentials:1.0.0-alpha05
androidx.credentials:credentials-play-services-auth:1.0.0-alpha05
Steps to reproduce:
On Passkeys prompt slider (or on biometry/pin prompt) rotate device (trigger configuration change)
Result: coroutineScope is canceled but credential operation is not, causing:
Expected correct behavior: Passkey operation is canceled correctly: