Obsolete
Status Update
No update yet.
Comments
vi...@google.com
jc...@xone.es
Another acceptable alternative could be that foreground services be actually considered foreground services for the purpose of activity starts.
Because, well, the app is "sufficiently" in foreground, as the notification is permanently visible while the foreground service is running, so you can rest assured that the user is aware of the app running.
Because, well, the app is "sufficiently" in foreground, as the notification is permanently visible while the foreground service is running, so you can rest assured that the user is aware of the app running.
vi...@google.com
Thank you for reporting this issue. We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.
sa...@gmail.com
I have a similar issue. My app has a flow that directs the user to grant the "modify system settings" permission. As soon as the user grants the permission, my app's activity in the background automatically launches itself so the user doesn't have to backtrack through the OS settings screens to get back to my app.
But the new Android Q behaviour considers this a background activity start even though it's triggered from an activity that is part of the foreground *task*.
But the new Android Q behaviour considers this a background activity start even though it's triggered from an activity that is part of the foreground *task*.
he...@gmail.com
Foreground services should be exempt since they're already required to show a notification.
This will break a lot of existing apps and APIs, please read:
https://www.reddit.com/r/androiddev/comments/b0t8np/android_q_to_prevent_startactivity_in_service/
This will break a lot of existing apps and APIs, please read:
da...@loylap.com
I work on business facing apps that require background launches from service broadcasts. The devices my app runs on are strictly 4.2.2, 4.4.4 and 6. Unfortunately I will never be able to target Q unless this heavy handed rule changes.
ad...@ramanidatascience.com
Some of the previous bugs in issue trackers on this very issue seem to have 'disappeared'. When I try to access them it says 'access denied'.
https://issuetracker.google.com/issues/128511873
How do we know how Google is addressing this? Or what the official response is to it beyond removing it from issue tracker?
Also, would Google built apps have this permission to launch activities from a background service? Google now has apps for payments, messaging, mail and all kinds of other things. If Google apps have a permission through direct access to the OS that 3rd party apps don't that pretty much is the definition of an unfair playing field. (pun not intended)
How do we know how Google is addressing this? Or what the official response is to it beyond removing it from issue tracker?
Also, would Google built apps have this permission to launch activities from a background service? Google now has apps for payments, messaging, mail and all kinds of other things. If Google apps have a permission through direct access to the OS that 3rd party apps don't that pretty much is the definition of an unfair playing field. (pun not intended)
as...@gmail.com
I would like to suggest removing this restriction for Accessibility Services. I have an accessibility app that is used by a lot of people with visual impairment or motor control issues to more easily open other apps, which they will not be able to do in Android Q.
[Deleted User] <[Deleted User]>
...
jc...@xone.es
Another acceptable alternative I can think of is doing exactly the same thing the OS already does in Android P with notifications. When the user usually dismiss an app's notifications without doing anything with them, the system asks you if you want to stop seeing them.
Similarly, Android could:
1) Track background activities launch.
2) If the user destroys the Activity without interacting with it, for example onUserInteraction() is never called, nOffendingActivityLaunchesCount++;
3) If the count surpasses a thresold, show a warning to the user giving him the option to force the app to shut the fuck up. Start throwing exceptions or ignore silently the activity launch command, maybe even offer the option to uninstall that adware app.
4) Do NOT provide an api to check if background activity launches are blocked. Legit app developers will not face this issue. Well, maybe someone may block launches without really knowing the consequences, but we all must compromise at some point.
Similarly, Android could:
1) Track background activities launch.
2) If the user destroys the Activity without interacting with it, for example onUserInteraction() is never called, nOffendingActivityLaunchesCount++;
3) If the count surpasses a thresold, show a warning to the user giving him the option to force the app to shut the fuck up. Start throwing exceptions or ignore silently the activity launch command, maybe even offer the option to uninstall that adware app.
4) Do NOT provide an api to check if background activity launches are blocked. Legit app developers will not face this issue. Well, maybe someone may block launches without really knowing the consequences, but we all must compromise at some point.
an...@gmail.com
Agree this break our remote controlled app launcher. The user is always in control from the remote end so its not as if our app is spamming the user with activity launches all on it's own. A foreground service with a persistent notification should be considered as exempt but perhaps coupled with a user setting to disable/enable it if apps are using it for the wrong reason.
da...@gmail.com
Anything that breaks automation apps is unacceptable. I have multiple running 24/7 on my mobile to communicate information to my home automation setup and do other things.
ee...@gmail.com
I don't see any feedback/changes in last weeks regarding this.
Is that possible to make this a general option available in settings for everyone?
"Disable restrictions by turning on the Allow background activity starts developer option"
Thank you
Is that possible to make this a general option available in settings for everyone?
"Disable restrictions by turning on the Allow background activity starts developer option"
Thank you
fe...@googlemail.com
at...@google.com
Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here
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.