IssueTracker

It's done by jamed-t he's the Ione respond to all the programs that is put in my phone .will call the police .

Even worse, then.
Granting the permission shouldn't kill the process.

We’ve shared this with our engineering teams and will continue to provide updates as more information becomes available.

@6 I think it's a mistake. They probably looked at something else.
It can't be by design. Close app when it's granted...

Here, made a new one with a sample and video:
https://issuetracker.google.com/issues/157681335

To reconfirm, this is in fact working as intended. Unfortunately there's no way to give the app these new specific permissions without killing it first. On the bright side, this should only happen once.

@8 Incorrect. It is a new bug. Didn't occur on previous versions of Android, and you can try it for yourself on previous ones.

Also, it can't be a good thing. Force-stopping an app because it asked nicely to grant a permission, and got it?!
It's worse than killing. It's force-stop. It is worse than denying a normal runtime permission.

It's not a bright side at all. There is practically no other permission that cause this terrible behavior. And it's not intuitive for users that once the permission was granted, the app is gone. It shows as if the app itself has a bug, not being able to handle the change.

Please avoid this. Users will complain just because you make bad choices. Don't put weird behaviors like Xiaomi does.

Please reconsider. Here:
https://issuetracker.google.com/issues/158018379

Can confirm the same with our app (APKMirror Installer) and 11 DP4.

@8 What are you talking about? Android 10 and below have handled this properly for years. You request the install unknown apps permission, the user approves it, and it's granted instantly.

@10 How can you agree that it's an acceptable behavior exactly?
Why do you think there is a need for it to be documented and written to the user? It shouldn't exist at all...

@11 Right. It was from API 23 , that the permission was created, and on API 25 that it was requested to be granted:
https://developer.android.com/reference/android/Manifest.permission#REQUEST_INSTALL_PACKAGES

It worked perfectly fine. It's not a new permission at all.

#9 Is on point. This is not acceptable and seems like an obvious bug that is being ignored due to release timelines. Kindly do not burden developers and users with such terrible UX.

As an extension to comment #8 - Unfortunately there's no way to give the app these newly granted permissions without killing it first, because we need to remount the storage view of the app to get the newly added permissions.

However this issue has now been logged internally as a feature request for further evaluation. We'll be following up on issue 158018379. Thanks.

@16 It is possible, because it was possible before. It's not a new permission at all.
There is no need to remount anything. Just grant the app the permission.
And as long as it doesn't have the permission, block it.
Do it as you did it before R. There is no need to break the UX. What about backward compatibility?

Why did you make the suggestion internal and the bug closed? Why do you not let others see it and star it, showing you how important it is?

Please if you don't fix this terrible UX bug on R, at least make some way for the app to recover: have an Intent that we send to it, which will restart it, or restore its state on your own (better for backward compatibility).

It doesn't make sense that I open an APK file via Chrome, and it will behave the same as crashing.

What #17 said. 💯

We're going to cover this regression on androidpolice.com, most likely tomorrow.

Re comment #17, indeed the permission is not new, but the way the filesystem and storage mounts are setup in Android R has changed significantly. When an app starts without this permission, it gets a view of the filesystem that doesn't allow writing to certain directories (eg Android/obb). Once the app has been granted this permission, that view is no longer accurate, and needs to be updated to a view that allows the app to write to certain directories. With the way the filesystem has been setup in R, changing that view on the fly is not possible. As mentioned in comment #16, we're evaluating internally. I'm just providing additional details why this doesn't work the way it did on Q.

@19 OK so fix it on R. Don't say it's a good thing. Don't say it's working as intended. Don't say it's not a bug.
It's a bug that is caused by new changes. Not by a new permission that you don't know how to handle or don't know how it should work.

If I take it to some random case that I made up now:
Users had photos being shown for each of their address book contacts. It worked fine for all versions of Android, showing the picture of the caller based on what's on the address book.
So suppose one day, since Google changed the way it stored the photos on its servers (or on the OS, doesn't matter), all users can't see the photos anymore.
When users and developers reported to Google about this issue, could Google say :
"It's intended. We made changes that caused it. All you have to do is to re-upload the photos for each contact and it will work again. The good new is that you need to do it once!"
?
It doesn't make sense. Make backward compatibility a higher priority in your thinking of handling new Android versions.
Users and developers shouldn't suffer because of those choices that you make, and it's a terrible excuse to say that because you changed something under the hood, the UX should be worse.
UX should be better over Android versions. Not worse.

It's not the first time Google breaks functionality and UX for no good reason.
Google broke all clipboard managers (or any other tool that needs it) by not allowing apps to monitor the clipboard in the background, except for very specific cases. One of them was for keyboards, and Google's Gboard had the clipboard managing capability, while almost all keyboard apps don't have this feature at all.
If Google had a clipboard manager app, it wouldn't have created this restriction.
If Google had the Play Store be available for all Android devices (even those that don't have it), it wouldn't have created so many restrictions and obstacles for app-stores apps.

I didn't say it was a good thing. I merely tried to provide some technical background for why this is not as simple as "do whatever you did in Q" or "just grant the app the permission", because it's not. As Navjot said, we are evaluating, and follow-up will be on bug 158018379.

@21 Closing this issue and others, marking they as "won't fix (intended behavior)" and saying "On the bright side, this should only happen once." , while as someone else said here that it's not documented at all and doesn't have a new API - is the same as saying it's not a bad thing but a good one that you want to have , something that is intuitive for users and developers to ignore.

The technical background should be for admitting it's a bug. Not about saying that it's intended, closing it. It shouldn't be an excuse to have a bad UX behavior, but an explanation of a bug, which will also be followed by "we are working on fixing it. Thank you for reporting it" .

Read the example I've shown you on @20 about the fictional case. It's the exact same as here. That's how you chose to behave, and currently, you still do, as long as this is marked as "won't fix" and as long as you consider it as a mere side-effect of some changes behind the scenes.

@21 In any way, it doesn't matter about the technical reasons and also the technical solution. Use the runtime permission mechanism for all I care...

Here, Android Police made an article about it, after I wrote about it on reddit:
https://www.androidpolice.com/2020/06/03/android-11-install-unknown-apps-more-cumbersome/
https://www.reddit.com/r/android_beta/comments/gvhxs2/android_r_app_granted_install_permission_and_got/

Maybe it will give you a clue about how others think of this matter.
Also maybe a tiny chance that you will change the way you handle new changes on the OS, including backward compatibility, UX, and API.
Currently I still see the status here as "won't fix" .

After the original reddit post of mine and Android Police's article, more came, and also another reddit, with more than 1,900 upvotes on it :

- https://www.reddit.com/r/Android/comments/gvv0rw/android_11_makes_installing_unknown_apps_more/

- https://androidcommunity.com/android-11-makes-it-challenging-to-install-non-google-play-apps-20200604/

- https://www.slashgear.com/android-11-doesnt-block-non-google-play-apps-but-does-add-a-hiccup-03623569/

The SG story seems fine, but wow the Android Community one is just dumpster fire in its current state.

I mean, even if it's "the new intended behavior", they could throw up a popup that says "to grant this permission, you will have to relaunch the app" instead of just killing it off with a force stop.

@25 I don't see where they are wrong there.
Actually not sure what "dumpster fire in its current state." means and how it helps in this conversation.
I'm trying to show that this issue is important.
Please focus on this, guys.

@26 agreed. This needs fixed. Allowing this as "Intended behavior" is not acceptable.

Seeing this wasn't fixed till now, reported about Beta 2:
https://issuetracker.google.com/issues/161584519

Its a fucking bug, don't say it's not. Also, you could inform the app that it needs to refresh its view to write to obb directory. The app can get the access when its next restarted or tell the user to restart the app. It's not really necessary for you to force close an app. You can just inform the app and leave handling the change upon the app.
If you need to shut down the app to grant it write access, inform the app to restart before it can write to obb directory, so it can fucking save its state and restart to it so the user doesn't have to fucking search the file again to install it. what if the app doesn't even need access to obb directory?
This is a bug and not an intended behaviour.

This is the same behavior that got Microsoft mobile  not off it's number one position several years back, which open the door for Android to take over.

Google need to rethink this philosophy of restrictions.

If we are able and willing to unlock the boot-loader, we should be allow to install any APK we want.

And now the issue exists on official, public version of Android R. Apps still getting killed, and most of them won't even be restored.

Requested to fix it here:
https://issuetracker.google.com/issues/168293637