Obsolete
Status Update
Comments
sh...@gmail.com <sh...@gmail.com> #2
Thank you for the feedback. We’ve shared this with our product and engineering teams for the possible consideration.
dy...@gmail.com <dy...@gmail.com> #3
We need more information to understand this requirement. Please help us with the same.
Please provide answers for the following questions:
1. Where do you see the reference documentation of intent?
2. What intents do not work properly in which android device?
Please provide answers for the following questions:
1. Where do you see the reference documentation of intent?
2. What intents do not work properly in which android device?
ma...@google.com <ma...@google.com>
uo...@google.com <uo...@google.com>
uo...@google.com <uo...@google.com>
at...@kraken.tech <at...@kraken.tech> #4
@3 An example is this one:
https://issuetracker.google.com/issues/154746519
As for a place that has documenations of Intents, here:
https://developer.android.com/reference/android/provider/Settings#constants_1
But there are many more of various other Intents. I had to use try-catch in many places, with fallbacks.
As for a place that has documenations of Intents, here:
But there are many more of various other Intents. I had to use try-catch in many places, with fallbacks.
lp...@google.com <lp...@google.com> #5
Thanks for the input.
at...@kraken.tech <at...@kraken.tech> #6
@ Comment#4 ,
As per the issue referencehttps://issuetracker.google.com/issues/154746519 , can you please let us know if this is discovered due to CTS testing? if so, please provide the bug report and test result so that our team can look into it further.
As per the issue reference
lp...@google.com <lp...@google.com> #7
@6 Guys all I know is that some devices crash apps due to an assumption on various intents that were documented.
Each time I noticed it, I used try-catch instead.
I want Android to be stable about these things. It doesn't make sense that when I tell it to reach some specific settings screen that's documented, the app will crash.
Each time I noticed it, I used try-catch instead.
I want Android to be stable about these things. It doesn't make sense that when I tell it to reach some specific settings screen that's documented, the app will crash.
an...@gmail.com <an...@gmail.com> #8
Thanks for the input shared. Since the scope of this feature is too big, could you help us to provide the intent list which will lead to a crash?
as...@gmail.com <as...@gmail.com> #9
@8 Perhaps. I wrote this issue a long time ago, but I'm 100% sure there are multiple Intents of various types that different devices didn't handle well, causing a crash.
Is there a way on Firebase Crahslytics to find such exceptions? I think it's ActivityNotFound, but sometimes it's even SecurityException ?
Each time I've found it, I've used try-catch or something else, to prevent it...
I could, if you want, publish a new version that will send such exceptions to Crashlytics again, but using non-fatal mechanism ("Crashlytics.logException") . But it will take some time to see those again.
Is there a way on Firebase Crahslytics to find such exceptions? I think it's ActivityNotFound, but sometimes it's even SecurityException ?
Each time I've found it, I've used try-catch or something else, to prevent it...
I could, if you want, publish a new version that will send such exceptions to Crashlytics again, but using non-fatal mechanism ("Crashlytics.logException") . But it will take some time to see those again.
Description
Jetpack Compose version: 1.2.0-beta02
Jetpack Compose component used: LazyColumn/LazyList
Android Studio Build: Android Studio Chipmunk | 2021.2.1
Kotlin version: 1.6.21
Android 12 introduced a new overscroll effect. Lists are now stretching. Unfortunately, with Compose, this same effect can cause LazyLists to "block" the scrolling of the lists from time to time.
That issue can be bypassed this way:
Providing called from
null
toLocalOverScrollConfiguration
causes the internal functionrememberOverScrollController
LazyList
(on whichLazyColumn
depends) to returnNoOpOverscrollController
which essentially doesn't produce any overscroll.Warning: The video linked below may cause epilepsy here .
You can find a video demonstrating the issue in a release build
Additionally, I created a simple Android Studio project which you can use to test the issue yourself. Everything required is contained within
MainActivity
. TheMainActivity
file also contains aConfig
object which you cause use to modify some aspects of the demo. It also includes a simple booleanDisableOverscroll
which you can set to true to disable the overscroll effect as explained above.