Status Update
No update yet.
Comments
fa...@google.com
- When a `windowSplashScreenAnimatedIcon` isn't specified and the default is used:
- no icon is displayed for any splash screen occurrence on API 30
- splash screen appears correct on API 31 except for notification case described above
- When `windowSplashScreenAnimatedIcon` is overriden:
- API 30 splash screens show the icon in all occurrences (launcher start or notification start)
- API 31 has the same behaviour as described, icon shown on launcher start, no icon on notification start
th...@google.com
This is intended. The splash screen is not shown on Android 12 when launched from notification. On Android 11 and below, there is no way to reproduce that behavior, so it's shown by default.
ha...@gmail.com
This results in a rather underwhelming user experience where a second or two of cold launch loading time treats the user to just a solid colour screen rather than one with appropriate branding that provides at least some visual feedback. This user experience appears like it would happen when the user enters the app via any means other than the launcher icon. This absolutely seems like it shouldn't be the intended behaviour. Especially for a platform that has so many different ways to enter an app with a cold launch
ra...@google.com
ha...@gmail.com
Using alpha 02 version of the compat library
ha...@gmail.com
I also agree that not having a splash icon for the cold launch other than from app launcher is not great user experience. It takes the same couple of seconds to show the app, but in one case user has nice (possibly animated) icon, in the other just blank screen to stare at.
Is there at least a way to find out if the icon is shown or not? I found out that OnExitAnimationListener is not called at all when the icon is not shown and it would be nice to know if we should expect that callback or not.
ha...@gmail.com
ha...@gmail.com
Another incredibly "smart" decision to encourage developers to drop this new API completely dead on the floor and keep using their custom made splash screens. Nowhere in the documentation is this even explained, nor is there any reason presented that justifies such unexpected difference across APIs, and no valid explanation why this should be an intended behavior in API 31+ when we are clearly expecting to see the splash screen icon when the app starts cold, regardless of the launching method.
Good thing I managed to come across this aberration before we integrated it further in our apps, as of now this new API will be completely dropped and we will definitely continue using our own Splash Screen implementation.
It's so disappointing to continue watching you guys continue doing absolutely unreasonably terrible decisions every single time something new is out. And it's not for the lack of feedback, which is what you guys ask us for, it's because once you have it, like in this case, you completely ignore it for what I can only assume to be attributed to pure laziness.
Such a disappointment once again.
[Deleted User] <[Deleted User]>
It's a general consensus
And it does not help that you keep hiding issues that others have opened to help us know what the progress is on those, they are all being set to private.
[Deleted User] <[Deleted User]>
FYI for anyone trying to get rid of the default splash screen that is completely forced in API 31+, you can set the style attributes to transparent and your splash screen theme as post theme, and force it to skip it entirely by triggering a UI draw.
Again we have to use hacks because Google devs thought that on top of making splash screen easier for us, they should also prevent us from opting out for no good reason whatsoever.
It is very sad to see Android app development being forced to become just web apps basically. Generic splash screen, limited functionalities, and so on.. Might just as well turn our apps into web apps and abandon this field of software development.
ha...@gmail.com
ma...@gmail.com
ma...@gmail.com
ma...@gmail.com
kh...@google.com
<item name="android:windowSplashScreenBehavior" tools:targetApi="33">icon_preferred</item>
[Deleted User] <[Deleted User]>
ki...@gmail.com
"For someone who had issues, I solved it by doing:
<item name="android:windowSplashScreenBehavior" tools:targetApi="33">icon_preferred</item>
Worked for 33 (Thanks) but not sure if how fix this issue versions below.
Description
1. Create a container cluster
2. Create two replication controllers for different services (A & B) on this container cluster
3. Create two NodePort services on the cluster to proxy the services from #2
4. Create two named ports on the instance group from step #1, one for each of the NodePorts.
5. Create a http(s) load balancer with backend for service A as described here:
6. Confirm that the everything is working as expected for service A
7. Create a second backend for service B
8. Create a host/path rule for the backend from step #7, configured against the url-map created in step #5.
What is the expected output? What do you see instead?
Expected: The load balancer supports traffic to both services when the backends are reporting healthy.
Actual: Traffic to service A always returns 502, despite both backends reporting healthy.
What version of the product are you using? On what operating system?
Google Cloud SDK 0.9.83
Please provide any additional information below.
There's nothing particularly odd about this configuration - just two kubernetes services running on a single container cluster, and configuring a load balancer to route to them based on path rules.
I'm able to reproduce this 100% of the time.