WAI
Status Update
Comments
ad...@google.com <ad...@google.com>
ad...@google.com <ad...@google.com> #2
We have passed this to the development team and will update this issue with more information as it becomes available.
mm...@gmail.com <mm...@gmail.com> #3
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.
it...@gmail.com <it...@gmail.com> #4
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 !
tj...@gmail.com <tj...@gmail.com> #5
This affects my accessibility app (Digilux) that lets users launch activities from the accessibility button provided in Android O.
co...@gmail.com <co...@gmail.com> #7
Google should be supporting and encouraging automation app developers and users, not limiting us!
an...@gmail.com <an...@gmail.com> #8
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?
sa...@google.com <sa...@google.com> #9
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:
lb...@gmail.com <lb...@gmail.com> #10
@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.
w....@gmail.com <w....@gmail.com> #11
What am I using Android for if I can't customize and automate? Isn't that the point? Give users the ability to choose!
jo...@gmail.com <jo...@gmail.com> #12
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.
mz...@gmail.com <mz...@gmail.com> #13
Still no improvement? Is this a joke?
w....@gmail.com <w....@gmail.com> #14
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
This will have huge ramifications, especially for automation apps, but every app starting or providing Activities which doesn't require user intervention, e.g. often using style="@android:style/Theme.NoDisplay", will be affected.
I haven't fully evaluated the affect or scope yet, but Android itself use lots of them, e.g. ACTION_DISMISS_ALARM, ACTION_DISMISS_TIMER, ACTION_SET_ALARM, ACTION_SET_TIMER, ACTION_SNOOZE_ALARM, PROCESS_TEXT, ACTION_RECOGNIZE_SPEECH, ACTION_VOICE_SEARCH_HANDS_FREE, MediaProjectionManager.createScreenCaptureIntent(), etc..
Google, please reconsider. This has nothing to do with "privacy", and will break countless of existing apps/APIs for no apparent reason. I also expect app users will be immensely annoyed by all the resulting (loud) PRIORITY_HIGH notifications they have to click every time.
X-post: