IssueTracker

Information redacted by Android Beta Feedback.

- Build Number: google/raven/raven:13/T3B3.230413.003/9957835:user/release-keys
  (Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)


Freezes again and needed to hard reset. Was scrolling chrome this time. Swiped back and the phone become unresponsive with the screen on. Nothing worked.

Debugging information
Google Play-tjenester
com.google.android.gms
Version 231312044 (23.13.12 (190400-519946965))
System App (Updated)

Android System WebView
com.google.android.webview
Version 561510134 (112.0.5615.101)
System App (Updated)

Network operator: Talkmore
SIM operator: Talkmore

Filed by Android Beta Feedback. Version (Updated): 2.33-betterbug.external_20230301_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

Information redacted by Android Beta Feedback.

- Build Number: google/raven/raven:13/T3B3.230413.003/9957835:user/release-keys
  (Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)


27.04.23 2209. Phone froze again. Now in the HBO app... Needed to hard reset the phone to get it up and running again. Please fix this fast. The phone is almost unusable#æ!

Debugging information
Google Play-tjenester
com.google.android.gms
Version 231312044 (23.13.12 (190400-519946965))
System App (Updated)

Android System WebView
com.google.android.webview
Version 561513534 (112.0.5615.135)
System App (Updated)

Network operator: Talkmore
SIM operator: Talkmore

Filed by Android Beta Feedback. Version (Updated): 2.33-betterbug.external_20230301_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

- Build Number: google/raven/raven:13/T3B3.230413.003/9957835:user/release-keys
  (Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)


29.04.23 15: 57  Frozen again. Now on the home screen. Phone was unresponsive, but now after approximately 1-2 min it restarted by itself

Debugging information
Google Play-tjenester
com.google.android.gms
Version 231312044 (23.13.12 (190400-519946965))
System App (Updated)

Android System WebView
com.google.android.webview
Version 561513534 (112.0.5615.135)
System App (Updated)

Network operator: PlussMobil
SIM operator: PlussMobil

Filed by Android Beta Feedback. Version (Updated): 2.33-betterbug.external_20230301_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

- Build Number: google/raven/raven:13/T3B3.230413.003/9957835:user/release-keys
  (Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)


29.04.23 16:07 AAAAND 16:11 FROZEN AGAIN!! NOW WHEN ENTERING FEEDBACK. BLACK SCREEN AND HAD TO HARD RESET. FFS! FIX THIS!!!

Debugging information
Google Play-tjenester
com.google.android.gms
Version 231312044 (23.13.12 (190400-519946965))
System App (Updated)

Android System WebView
com.google.android.webview
Version 561513534 (112.0.5615.135)
System App (Updated)

Network operator: PlussMobil
SIM operator: PlussMobil

Filed by Android Beta Feedback. Version (Updated): 2.33-betterbug.external_20230301_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

- Build Number: google/raven/raven:13/T3B3.230413.003/9957835:user/release-keys
  (Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)


Froze again when searching apps... Coman google. Fix this phone breaking bug!!!

Debugging information
Google Play-tjenester
com.google.android.gms
Version 231312044 (23.13.12 (190400-519946965))
System App (Updated)

Android System WebView
com.google.android.webview
Version 561513534 (112.0.5615.135)
System App (Updated)

Network operator: PlussMobil
SIM operator: PlussMobil

Filed by Android Beta Feedback. Version (Updated): 2.33-betterbug.external_20230301_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

Information redacted by Android Beta Feedback.

Calm your tits. It's the first release of a beta.

We have passed this to the development team and will update this issue with more information as it becomes available.

See also:
https://issuetracker.google.com/issues/128553846

Agree with Author. An opt-in or permission functionality to select which apps may start background activities would be sufficient. The rationale for the restriction is to increase user control of what occurs on their phone - forcing them to blanket restrict all of their apps from using this feature with no alternative removes control from the user, rather than adds it.

I use automation apps to launch apps contextually automatically (in particular, a music service when I pair to my car or speakers) and streamline my day-to-day. There's no reason to remove functionality that a user goes out of their way to add to their device in the interest of "giving more control". Let the user decide what the apps on their phone should be allowed to do. Display a warning if necessary and treat it as a specialty permission like autofill and overlays. It's as simple as that.

Agreed, I use tasker for everyday automation... This would really suck for me. Although I would still be able to flash another ROM, which I really don't want to.

I have several complex automation profiles which make my life and ride in the car a lot easier and more safe.

Agreed. I'm working on a VOIP app. When receive a push, we startActivity to show incoming call UI from FcmService. Please consider this use case.

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 !

I honestly can't believe that yet another upcoming restriction is causing trouble for tasker and possibly the autoapps. I use these apps extensively on a daily basis for lots of completely different uses and to keep having a constant threat of something messing with my daily use by crippling very useful apps is insane! This must be a nightmare for developers of legitimate apps that are genuine and amazingly useful. Do please consider some sort of exception for tasker and all the Autoapps as i honestly can't see myself using Android without there customisability and usefulness ... Keep up the hard work João and thanks for constantly battling to keep your apps non-restricted and functional!

Come on, Google. This is definitely not what we want. Having able to control our devices is the reason why we stick to Android.

We want android because we want freedom of choice. It's that simple. Good idea to just give us the choice. Very important

Also pitching in that I agree with the author.
I was shocked that Google haven't given the user an option to disable this on a per-app basis as it's such an obvious solution. Not just automation apps but so many apps would be affected by this.

The idea behind it is good, but we definitely need a way for users to be able to disable this behaviour if they so wish.

Thank you #11 for passing along, it's very much appreciated. And thank you OP

Agree with all that has been stated in this thread. Removing the ability the launch apps from Tasker is a deal breaker for me and would cause me to seriously look for an alternative to Android.

Agree with.

Please give an option to disable.

Thank you very much

Agree with author

From this last 3 month, I had this feeling that Google has launched a crusade against Android developers...

Agree with Author. If i can't automate my phone where would be the freedom that mighty Android provides me.

I think the intention here is to root out malicious/spam apps, but I think that has to be on a global level through Google Play analytics based on a broad range of user feedback. Disabling a feature that most apps are using to improve the user experience would actually make users complain about lost functionality in the "upgrade".

Agree with Author. It's a great new feature, however there should be a way for the user to disable this feature for specific apps.

This should not be forced on all. Please make sure there is a permission to override this, Google.

I also agree with the author on this. This is a good feature to have, but it would also be good to give the control back to the user to allow them to opt out for specific apps. If we cannot opt out then this will limit what we can do with Tasker. I have been relying on Tasker on a daily basis for a number of years now and I believe Tasker is one of the apps which make Android standout from the other OS available. So please allow us to opt out and have some control over our devices.

This is going out of control. PLEASE STOP THIS GOOGLE! STOP KILLING ANDROID like this. We don't want another iOS and that's why we are here taking you from zero to hero just because you provided us the freedom and customization. I am an Android developer who spent 5 years of his life with the platform and I feel cheated when I see this. I am already affected by your READ_SMS and READ_CALL_LOG blunder, please, I don't have the capacity to suffer more!

This is going out of hands now. Google please don't turn Android into iOS in the name of user privacy and security.

This would kill apps like Tasker. I've been using Tasker for seven years,  without it the use of my phones would be very cumbersome. Without the possiblity to automize annything I see no reason for not buying an Iphone the next time.

Agree with the autor. One of the reasons why I use Android is because of the freedom and possibilities that it allows me. If this changes why not opt ​​for another system like iOS that is clearly better optimized?

My wife has an apple because she didn't want to think about the automation of her phone, and it's useless.  I like the idea of security, but I should have the choice to program my technology.

From a privacy perspective, I don't think it is unreasonable to allow foreground services to launch activities.

This is also another step in making alarm clocks on android less reliable. It's already quite a struggle with all the different API versions, OEM battery managers, directBoot mode etc. Now you want to disable presenting an activity from the background. For example, what if the user disabled notifications for the app (e.g. because he didn't like the push notifications)? Then the alarm just won't have a chance to go off?! People are going to be late for work.

Adding an option to turn off this restriction is nice, but will only add another layer of annoying requirements and please-check-your-settings alerts (needed for about 50% OEMs) before one can set his alarm. I believe that pending intents from setAlarmClock method should be allowed automatically to present an activity from the background.

I agree with the author and feel that this would hamper the android experience. There should atleast be an option for user to choose or in this case disable selectively.

Agree with the author.  

Implement security/privacy by introducing new functionality, not by removing features.

I agree.
While privacy should be a priority, Android is all about freedom, and background apps are many of the reasons why my phone is so useful. Restricting this is not the way to proceed.

Agree with the author.

I agree!

And I forgot. Also bring back the write storage permission!

I agree!!!

I agree with the author!

Google should be supporting and encouraging automation app developers and users, not limiting us!

I agree with the author!
The rights should not be removed!
Users would be restricted!

From the Q Beta announcement post:

> We've also seen that users (and developers!) get upset when an app unexpectedly jumps into the foreground and takes over focus.

Focusing on user privacy and predictable device behavior is a Good Thing™️. Frankly, given both the ease of abuse of any Service launching an Activity, and the difficulty identifying such offending apps, I feel it's long past the point where Android *should* have some restrictions here.

But implementing a hard line "Services are no longer, under any circumstances, allowed to launch an Activity" rule feels very draconian. To me it's a bit like the headmaster cancelling recess for the whole school because a number of kids were misbehaving during break. And this is not a change with a legate privacy position such as the recent (and, to my mind very reasonable) READ_CALL_LOG and READ_SMS changes.

The suggestion to replace a Service starting an Activity with a high-priority notification will work for some apps, but it's clearly not applicable for many other existing, legitimate use cases. There's also the reality that users can blanket disable all notifications for an app via the System Settings, creating the potential situation where an app that worked fine on Pie with disabled notifications will suddenly become useless upon a device being upgraded to Q.

I feel it's reasonable to expect the Android team to do better than suggesting a workaround that only serves a limited subset of use cases. Instead, the goal should be a solution that prevents bad actors from creating bad user experiences whilst also allowing good actors to continue to provide users with the app and device behavior they have become accustomed to up until Q.

Instead of Q Beta 1's blanket "No Service can launch an Activity" approach, what if:
1. A new LAUNCH_ACTIVITY_FROM_FOREGROUND_SERVICE permission is added.
2. This permission must be manually enabled by users before an app can use it.
3. If LAUNCH_ACTIVITY_FROM_FOREGROUND_SERVICE is granted, a foreground Service for that app is allowed to launch an Activity.
4. Android keeps a short-lived record of all times any app launches an Activity from a Service. This information is displayed to users via the System Settings somehow, allowing users to easily revoke this permission.

Such a solution would:
• Stop the stated problem of "users (and developers!) get[ting] upset when an app unexpectedly jumps into the foreground and takes over focus".
• Allow people to continue using apps that rely on launching an Activity from a Service as they have to this point.

As a long-time Android developer and user, I feel Q Beta 1's Service/Activity changes severely limit Android's customizability and really risk taking away a significant part of what makes Android Android. I hope the Android team considers reconsiders their position here.

- Chris Lacy.

Please remove this restricted. Before the phone permission was removed, I received many bad reviews. I don't think start activity from service need enable the permission, it makes less UX and you should check and remove apps show advertising when exit app.

User don't think as developer. They don't take care too much, they only take care simple and use easy, response their target.

Thanks!

> The app has a visible window, such as an activity in the foreground.

Will some devs will try to work around this by having a 1 pixel transparent window tucked away somewhere?

This will also break use cases like Android Auto's autolaunch upon a specific bluetooth connection. User intent is not necessarily launching another app from the foreground app and it could be triggered by other actions (IFTTT etc). At the very least, users should be given a package specific option to override the default behavior.

This change will totally break a huge part of my app and my revenue. My app allows users to create volume presets. When a user plugs in headphones or connects to a specific Bluetooth device, an activity appears that will show all their volume presets and they can choose which preset to use for whatever headphones they're using. Please Google, at least add a new permission. Add as much scary terminology as you want to prevent users from enabling activity launching in malicious apps. But please I beg of of you allow this to continue to be an option for apps that really need it like automation apps such as mine.

I literally feel sick to my stomach right now. I worked so hard on this. The app does more than just that, but it's a much loved feature of it and one that I use ALL the time myself.

Thank you and please please consider adding permissions or literally anything that will allow automation apps to continue working correctly.

This change is a huge problem especially for apps used for Mobile Payments via NFC.

Upon tapping a phone to a POS terminal, our Banking App can show three possible screens:
1- Payment successful screen with card used for payment and payment amount
2- A screen showing payment amount, card to be used and telling user to enter the card PIN and tap again
3- Payment failure screen notifying user to tap again

In all 3 cases customer MUST immediately know that there is financial transaction attempt being made with the phone. Reasoning is very simple: It is initiated by an action of the customer (or by an attacker with a small portable POS machine!) and has financial consequences; therefore, these screens must get the full, only and immediate focus of the customer.

Suggested workaround is "high priority notifications" with full screen intent.

The biggest problem of this is the "Do Not Disturb" mode. If that is enabled, customer does not even see a "heads-up notification". A financial transaction is not something to be accounted within "Do Not Disturb" context. Customer must be disturbed as this has financial impact. And let me remind that, it is the customer that is actively taking an action by tapping the phone.

Yet another problem is the inconsistency of the flow. If the phone is locked, then customers see a notification "being created" while at the same time the related screen is immediately shown (although again not the case for "Do Not Disturb" mode). But if the phone is unlocked and then customer taps to POS device while app is not in foreground, then customer sees a "heads-up notification" not the screen (again not the case for "Do Not Disturb" mode). Even worse, customers will usually see the "heads-up notification" as they would usually touch to the fingerprint sensor (either on purpose, or by mistake) and unlock the phone prior to tapping due to the physical tapping action that they will perform.

Furthermore, in case of screen (1), this change would add an extra step for an action which must be done within the POS timeout period (usually 30 seconds): Customer must now also tap the notification, then, change card if needed, enter card PIN and tap the phone to the POS terminal again. Tapping the notification is an interruption in the flow that does not generate any value; yet even inconsistent in this time-constrained flow.

What customers expect from "Mobile Payment" is that it should be fast and safe; yet this change would make the mobile payment flows counterintuitive, more complicated and inconsistent; thus, raising questions on customer's mind over reliability of Mobile Payments.

There are more of us than you might imagine, and for some of us, being able to use apps like Automate is why we choose Android. I use this for highly customized attention management that I can't get from any of the apps on the market.

I understand where Google is coming from with this change, I like the idea behind it in theory in that activities should only be started as a result of user interaction, but I think the way Google chose to implement is completely wrong. Google, please understand that touching the screen is not the only way a user can interact with a device, there are a ton of other ways (voice, connected accessories, hardware button presses, NFC etc), and making activities launchable only from other activities is just plain stupidity.

Poor decisions like this are killing android. Honestly, I would LIKE to give an opportunity to phones with windows. As a developer or experienced user when you constantly lose functionality on every update, that make you jump into other SO.
Root also should be a featured option in developer settings.
Android is more similar to Apple in every step They do

Agree with OP. Hopefully this was an early April Fool's joke.

What confuses me the most about this is that INTERNET is a not a runtime permission, but launching activities from the background is most likely getting axed. Considering that most apps need internet access, the Play Store could automatically grant the internet permission on install unless the user disables auto grant.

More generally, this obsession on reducing pop-ups from a background service is showing Google's focus on optimizing the mobile user experience and missing the boat on the post-mobile era that's slowly but surely unfolding. Android was such a success because it provided the flexibility in the mobile world that was missing in the Windows that was designed for desktops. We are entering the world of the smart-<insert name of device> (not just phones). Smart-cameras, smart-speakers, smart-cars, smart-alecs (always been there)...

Here are a few billion dollar product ideas some of which are already winding through all the different incubators
- A menu based voice ordering kiosk that can be deployed at any fast food restaurant
- Recognizing visual cues for solving a specific task. Think the cameras at an Amazon Go store but for any store.
- A digital signage billboard that dynamically serves ads based on who is walking in front of it. (kind of like online ad serving in the real world)

Obviously, there are a lot of much humbler applications that are already pretty widespread i.e. a kiosk or a remotely monitored security camera.

All these products don't have users in the typical sense. The device runs only single app, and users expect a certain behavior when interacting it. The user interacting with the app isn't expected to have executive control over the device.

Killing background services is another step towards making Android unsuitable for all these product cases! I.e. opening up opportunity for a new smart device oriented OS.

Agree with the OP. Tasker, Automate, Macrodroid etc are why we love Android.

This completely breaks a widget in my background tracking app. I have a widget to enable user to control their gps tracking service from launcher. Earlier they broke the ability to start a Service (foreground service, mind you) from a  widget, so now I have to resort to starting an invisible activity which starts a service. After this update, I can't even use activity to start a service which leaves my widget completely useless. Stop ruining everyhing that doesn't match your "imagined" application use cases. There's much more useful applications than you think.

I think your issue is not related to this restriction. You can still start actvity from a widget or notification via PendingIntent.

Only PendingIntents are exempted from this restriction as it requires user interaction to launch the intent. More info:
https://developer.android.com/preview/privacy/background-activity-starts

I agree with the OP as it will break many other apps.

I agree with author.

this is not good, Google.

I also agree with the author.

Please consider an exemption for accessibility apps.  Many visually impaired people and people with motor control issues use my app to more easily launch applications.  This completely breaks that functionality.

Consider making this a permission the user can approve. Almost every new Android release causes us to spend many hours just to update things after Google changed established rules. This is quite some money which could be spent to innovate instead.

100% agree, the main reason people use Android is for it's customizability and the functionality and near limitless potential and it is open source. Now start removing said customizability and functionality there will be no reason to use Android and to flock back to iOS (apple).

I know this is for security reasons but allow the user to be able to select which apps that he/she seems safe to them and allow them to start in background

Agree with author, Google, respect power users

Please consider allowing the user to give permission to certain apps (such as Tasker) to be able to launch activities from background. I use this functionality many times every day, as do many other users.  Thanks.

We use Host Card Emulation to enable NFC payments for tens of thousands users in our mobile banking application. The payment is processed in a background service and the result is displayed to the user - possible results are success, failure or required user authorization, all displayed as a full screen activity started from a service.

From Android Q, we have to migrate to using high priority notification to notify the user about the payment result. But it comes with following problems:
- The notification isn’t displayed in Do Not Disturb mode unless the user directly enables it in settings for that notification channel. That means users could pay without any visible feedback on the phone.
- Users could disable notifications for our app or just that channel and never receive feedback about payment.
- When the phone is unlocked, the full screen intent associated with the notification is not displayed until the user taps on the notification, resulting in one more tap needed to process the payment in case the authorization is required.
 
Is there anything we are missing regarding those issues? Is there any way we can overcome this?

I agree with author. If you want to fight with malicious and adware apps in Google Play, just improve your play protect, why we are must suffer if your team that develops play protect is can't resolve this problem?

We are providing a hardware based solution. The related app runs in background only, using a USB attached device to gather/forward data. For reasons out of our control, we provide an option to automatically restart the app, should any issue with the USB or Android device occur. This restart will no longer be possible with this change. Due to the nature of the app/environment, the user often will not have time to manually restart. This directly lowers the safety of the user.

This is just an example. 2/3 of our apps will need a considerable amount of changes to keep them working.

The following is also very concerning. From the developers blog:

This behavior change applies to all apps running on Android Q, even those that target Android 9 (API level 28) or lower. In addition, even if your app targets Android 9 or lower and is originally installed on a device running Android 9 or lower, the behavior change still takes effect after the device is upgraded to Android Q.

So this change affects app versions currently running in production and will cause many apps to not work anymore on Q. This forces developers to quickly release new versions of their apps to compensate or accept tons of one-star reviews, which can destroy apps completely. Changes over established API boundaries are a very bad thing. Why Google?

I'd say we could just punish Google by explicitly stating in our apps when the user tries to use X functionality in their shiny new phone that Google intentionally broke it with no real replacement.

OK
<buganizer-system@google.com> schrieb am Do., 16. Mai 2019, 19:12:

Even stating in the apps description that Google have broken some functionality won't stop people leaving negative reviews. Just take a look at the number of 1-star reviews for root-only apps (that explicitly specify root required in the app name) from users that don't read requirements.

If an app is running a foreground service in the background, Android Q should consider to add it to the whitelist and enable it to start an activity in the background as it has displayed an on-going notification on the notification panel.

The following page:

https://developer.android.com/preview/privacy/background-activity-starts#conditions-allow-activity-starts

States:

Note: In a future beta release of Android Q, apps that have been granted the SYSTEM_ALERT_WINDOW permission by the user can start activities in the background. Keep in mind, though, that apps running on Android Q (Go edition) cannot receive this permission.

Light at the end of the tunnel?

The author is correct.  Security is nice, but don't completely kill good workflows!  I believe something similar to Opt out options for the battery optimization can be used here.  Allow certain apps to launch other apps in the background as a compromise that makes this feature work, but in an acceptable manner.

Completely agree. Protect the majority by not giving permissions by default, but allow the minority to use your system to the best of its abilities. Same goes for access to copied clippings. You're crippling entire apps and use cases with this. Have access to copied texts off by default, but have the option to allow it for certain apps (clipper etc.).

Has anyone checked in Q Beta 4 that having the SYSTEM_ALERT_WINDOW permission (after asking user) is working for starting activities in the background ?

#79, I've tested it and it works.

I haven't checked it yet.
But I found the following page has been updated.

https://developer.android.com/preview/privacy/background-activity-starts#conditions-allow-activity-starts

States:
The app has been granted theSYSTEM_ALERT_WINDOW permission by the user.

I tested out my app, that launches an activity from the background, and it works after adding these changes:
1) add permission SYSTEM_ALERT_WINDOW in the app manifest
2) prompt the user to enable my app to "Display over other apps" in settings->apps&notifications->Special app access

This was with Q beta 4

If Android is going to be crippled in this way we will have to look for an alternative.

If I was happy with these restrictions I would buy an iPhone. I use android because I can make it my own. I really don't like the way this is going. I am a very open user as long as my phone does what u want so happy to click whatever to make this work for me. Thank you for considering this and other restrictive changes to the operating system. Ie. Mot letting voice unlock the phone when driving. Thanks, that was a good one. Please don't so it again.

Stop crippling the only viable phone OS for people to automate tasks.

is this a joke? this is a nightmare, and honestly grounds for monopoly lawsuits, because you know this restriction is wrong and exempt your own apps from it.
ive spend 2 days so far trying to get my own utility app to work, I cant even give my own app permissions to do what it was doing before without rooting the phone...

im sure forcing people to root their phones to use a basic functionality (which they WILL do) is much better for security and privacy than allowing users to decide for themselves what they want to do.

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

@88 You didn't write about backward compability at all. The restriction ruins how apps behave.
It breaks them unless the developer will update their apps to handle it.
Why not present the user an option to whitelist such apps from this restriction?
Why not offer a more direct way to be an exception? Why do you present us a weird list of exceptions, all have nothing to do with allowing it?

A direct whitelist would be so nice. The default behavior for unintentional power consumption can be as convoluted as your product teams wants I suppose, but as a user with a powerful computer in my pocket, it would be really nice for it to deterministically perform actions I explicitly specify, even if those appear really spendy on the power budget. Direct user control is one of those great differences between android and other platforms and this could be a differentiator. Plus it would shore up the mind-boggling platform differences between vendors in how they implement things so there was at least one way to know (for example) that your alarm clock program works (c.f. https://dontkillmyapp.com/)

I'm very angry. When we watch google dev videos, your people always say how open they are to community. But it is a big lie!

Yes this is the wrong decision Google, please rethink this. I would be an android user forever unless you lock android down too much which it looks like that is the road you're headed down.  Don't force people to root their phones or leave Android if they want this type of functionality!

Yes , also i agree

Consider adding an opt-in/out option, Android will lose market otherwise.

Google being Google in its ivory tower.
"yes, we hear you, but you know what? WE KNOW BEST"

Time to ROOT since Google will not provide access, and I am SURE there is a malevolent reason for this beyond what we could imagine ala Minority Report & Black Mirror.
Something Wicked this Way Comes.

Google seems to be following Apple's path.. I totally agree with the author. There must be permission for apps

Totally agree with this post. Android is becoming like iOS, very restrictive.

Now my digital signage app is not opening automatically when people turn on the TV with a simple BOOT_COMPLETED... Works perfectly on Android 9...