Obsolete
Status Update
No update yet.
Comments
vi...@google.com
jc...@xone.es
We have passed this to the development team and will update this issue with more information as it becomes available.
vi...@google.com
This also affects payment apps that start activity from HCE service when user taps the phone on NFC terminal, like our company's Wave2Pay or even your own Google Pay.
sa...@gmail.com
Please don't harm automation apps, at least allow foreground services : this is affect a lot of app (include mine, Tasker, MacroDroid, ...)
You take down SMS & Call Log permissions, now you take down all entire automation apps.
This will ruin a lot of apps, and developers life...
Please reconsider your decision or propose an alternative !
You take down SMS & Call Log permissions, now you take down all entire automation apps.
This will ruin a lot of apps, and developers life...
Please reconsider your decision or propose an alternative !
he...@gmail.com
This affects my accessibility app (Digilux) that lets users launch activities from the accessibility button provided in Android O.
ad...@ramanidatascience.com
Google should be supporting and encouraging automation app developers and users, not limiting us!
as...@gmail.com
Agree. We have a remote control automation app but the user is always in control of the launch of activities from the remote. Can Google not consider allowing the user to enable/disable this from the security tab and or insist that a foreground service with a persistent notification is exempt?
[Deleted User] <[Deleted User]>
Once again, thank you for submitting the feature request. After following up with our product and engineering teams, the feature request will not be considered at this time.
Note that the final Android 10 release incorporated several exceptions to when activity starts are allowed from the background - see here:https://developer.android.com/guide/components/activities/background-starts#exceptions
Note that the final Android 10 release incorporated several exceptions to when activity starts are allowed from the background - see here:
jc...@xone.es
@9 What about backward compatibility?
Why not present a new permission that will ask the user if it's ok for this app to open the Activity in the background?
This way you can still avoid breaking apps, while letting the user know about it.
Why not present a new permission that will ask the user if it's ok for this app to open the Activity in the background?
This way you can still avoid breaking apps, while letting the user know about it.
an...@gmail.com
What am I using Android for if I can't customize and automate? Isn't that the point? Give users the ability to choose!
da...@gmail.com
I'm confused, is Google merging with Apple?
I don't think people will be able to distinguish Android from iOS for much longer.
I don't think people will be able to distinguish Android from iOS for much longer.
ee...@gmail.com
Still no improvement? Is this a joke?
fe...@googlemail.com
PLEASE reconsider!
I automate sooooo many things with android apps that listen for Bluetooth
changes and timers and all sorts of other things. Listeners for actions to
be taken on when other notifications are taken.
On Mon, Feb 8, 2021, 3:51 PM <buganizer-system@google.com> wrote:
I automate sooooo many things with android apps that listen for Bluetooth
changes and timers and all sorts of other things. Listeners for actions to
be taken on when other notifications are taken.
On Mon, Feb 8, 2021, 3:51 PM <buganizer-system@google.com> wrote:
Description
QPP1.190205.018.B4
* Is this a regression from P to Q?
No.
* What device are you using? (for example, Pixel XL)
Google Pixel 3
* What are the steps to reproduce the problem? (Please provide the minimal reproducible test case.)
1) Start a background Service, IntentService or JobIntentService
2) Launch an activity while no other activity is already in place.
* Issue Category e.g. Framework (platform), NDK (platform), Hardware (CPU, GPU, Sensor, Camera), ART (platform), Runtime Permissions etc
Framework.
* What was the expected result?
This behaviour should not be blocked 100% of the time, as there are use cases where Android cannot determine that the background activity launch is not a user triggered action. Deciding that just by checking if there is any activity in foreground is insufficient. Adding a new permission would be nice.
Please read the use case I explain below.
* Can you provide the API document where this expected behavior is explained?
* What was the actual result?
The warning toast about this behaviour being blocked in future release appears.
* Relevant logcat output.
2019-03-15 10:54:41.625 1407-3564/? I/ActivityTaskManager: START u0 {act=android.intent.action.MAIN cat=[
2019-03-15 10:54:41.625 1407-3564/? W/ActivityTaskManager: Background activity start [callingPackage: com.xone.android.framework; callingUid: 10291; isCallingUidForeground: false; isCallingUidPersistentSystemProcess: false; realCallingUid: 10291; isRealCallingUidForeground: false; isRealCallingUidPersistentSystemProcess: false; originatingPendingIntent: null; isBgStartWhitelisted: false; intent: Intent { act=android.intent.action.MAIN cat=[
* Link to captured Android bug report (shared privately in Drive.)
Not really needed here, but I can provide it on request.
* Optional: Link to any screenshot(s) that demonstrate the issue (shared privately in Drive.)
-------------------------------------------------------------------------------------------------------------------------------------------
Our app is a framework for developing apps. On app start, it launches a background service that opens a local TCP port to listen for incoming websocket connections from our IDE in the browser, to upload applications and launch them. The developer might have his own app already open or not, he may have pressed the home button.
In any case, the background activity start is always a user triggered action, but Android cannot know this fact.
Other apps which may have a socket connected remotely might suffer from this. Or worse, other app users might not have easy physical access to the device, like embedded kiosks and such.
Please add a new permission (runtime or not) to allow this.