Status Update
Comments
da...@gmail.com <da...@gmail.com> #2
Thanks for reporting this. We will investigate this and get back to you once we have an update.
wu...@google.com <wu...@google.com> #3
Branch: androidx-main
commit 5dd50789a7bbcba846f41e4265bd5411fb542b02
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Wed Dec 21 17:16:55 2022
Fixed "clickable" modifier doesn't work with ImmersiveList
* In the "focusableItem" modifier, we add a "focusable" modifier. Now, if the user adds the "clickable" modifier, the
"focusable" modifier added by us has no effect. So, we are now removing the "focusable" modifier
from it. Now, user will have to manually add "focusable()" or "clickable()" along with
"focusableItem". Since this is an immersive list item, ideally, the item will always be clickable.
* Renamed "focusableItem" modifier to "immersiveListItem" modifier which is a better name for the new API and also this
makes it clear, while reading, that this modifier is only part of "ImmersiveList" and also makes
doesn't hint that "focusable()" modifier would be auto-applied
* Moved the immersive list component out of the sub-package
* Added missing ktdocs for params
* Added sample immersive list usage
Bug:
Test: Updated tests
Relnote: "Renamed `focusableItem` to `immersiveListItem` and removed `focusable()` modifier. Now
users will have to manually add `focusable()` or `clickable()` modifier along with
`immersiveListItem`"
Change-Id: I1fd6c8cca3d7f4e810ad838ec1aad0b3c3e41450
M tv/integration-tests/demos/src/main/java/androidx/tv/integration/demos/ImmersiveList.kt
A tv/samples/src/main/java/androidx/tv/samples/ImmersiveListSamples.kt
M tv/tv-material/api/current.txt
M tv/tv-material/api/public_plus_experimental_current.txt
M tv/tv-material/api/restricted_current.txt
M tv/tv-material/src/androidTest/java/androidx/tv/material/ImmersiveListTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/ImmersiveList.kt
sc...@google.com <sc...@google.com> #4
The issue has been fixed and merged to Android Open Source Project. The fix should be available in the next tv-compose release (Version: 1.0.0-alpha04).
Closing this ticket. Feel free to re-open in case of any issues.
Thanks 😀
sh...@google.com <sh...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
da...@gmail.com <da...@gmail.com> #6
One of our project members can potentially get their hands on one of these devices but we currently don't have access to one. It's probably a lot easier for you folks to get one since we can't really afford to buy phones.
Ideally you could get some of these cheap Indian/Chinese phones for the CameraX device lab.
This Jio device is Google certified but in my experience most non-Pixel phones are pretty far from genuinely passing the CTS and have a lot of failures that aren't just flaky tests. I'm not sure how they get their devices certified but apparently there are waivers. Google doesn't do the certification but rather third parties do, and it's possible they're simply cutting corners or acting in a corrupt way. Usually there are a lot of failing CTS Camera tests. It doesn't help that a lot of those CTS Camera tests are super flaky without a high quality device and a proper testing setup with proper lightning, etc. They can still fail from flakiness even with that setup. Probably why they can so easily skip meeting these requirements, since the certification companies are used to flaky / failing tests and aren't really doing their job properly.
da...@gmail.com <da...@gmail.com> #7
We have a project member in India who could buy one of these phones and since they're so cheap (around $80 or something) I could cover that but in general I don't really want to be buying phones we don't really need.
sc...@google.com <sc...@google.com> #8
Thanks for the informations. You are right, it's possible that the devices are not genuinely passing the CTS.
Regardless, we will fix this in CameraX. (Thanks for letting us know BTW)
We will also try to get one of these device to test if there are other issues.
Scott
tr...@google.com <tr...@google.com> #9
This crash looks similar to the one in
sc...@google.com <sc...@google.com> #10
1) Fix it generally
2) Have a quirk for this, only enable the fix when device has this quirk.
The problem with the quirk is that it is too easy to miss some other devices that have this issue too.
Having a general fallback that works reasonably can fix the issue for all problematic devices.
(In these two cases, they are both reasonable to return false if the key access failed)
But I do think it has benefits to have a quirk so that we know exactly what workaround we handled in CameraX.
Maybe , we can have a type of quirk or workaround that we apply generally for all devices ?
WDYT?
mi...@google.com <mi...@google.com> #11
I had similar considerations while adding the try-catch code (aosp/2092403). I want to have a quirk to document the workaround we made, but it would be a little weird that the quirk should always return true on the device quirk check. I was wondering if it is possible to have another type of quirk, e.g. a function with comment in quirk format.
ap...@google.com <ap...@google.com> #12
Branch: androidx-main
commit 874ef5abba7929d0110fd54392ae9d8ee91003f0
Author: mingdatsai <mingdatsai@google.com>
Date: Mon May 09 20:32:42 2022
Catch CameraCharacteristicsBaseImpl exceptions
Some devices may throw AssertionError, which is not the expected
behavior, when failed to get CameraCharacteristic. When that happens,
we catch the error and return null to workaround it.
Bug: 231701345
Test: ZoomControlTest, ZoomControlDeviceTest &
Camera2CameraControlImplDeviceTest
Change-Id: Ia248ae5580b9d4a0949f4448ccbafcedd1ba7b9b
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/ZoomControlTest.java
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/ZoomControl.java
M camera/camera-camera2/src/androidTest/java/androidx/camera/camera2/internal/Camera2CameraControlImplDeviceTest.java
M camera/camera-camera2/src/androidTest/java/androidx/camera/camera2/internal/ZoomControlDeviceTest.java
mi...@google.com <mi...@google.com> #13
We have tested both Android 11 and Android 12 versions on JioPhone Next and couldn't reproduce the bug. I'm guessing it might have be fixed in an earlier device update. The code to handle the AsserionError has been merged, and will be included in a following release.
da...@gmail.com <da...@gmail.com> #14
That makes sense since we're not seeing enough of the errors for it to be impacting all of them. Play Store doesn't provide more than the major version though and we don't have any of our own crash reporting.
mi...@google.com <mi...@google.com> #15
Thanks for the information, it seems match with the guess.
ju...@google.com <ju...@google.com> #16
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.camera:camera-camera2:1.2.0
Description
We're receiving these crash reports for our app on the Play Store (https://play.google.com/store/apps/details?id=app.grapheneos.camera.play ). I'm unsure why it's happening, but perhaps you can get one of these devices and reproduce it. Ideally, CameraX could at least start catching this exception and turning it into an error surfaced to the app.
We're mostly seeing these crashes from the Jio JioPhone Next which is a very widely used, very cheap device in India. The crash traceback is nearly identical across the around 5 device models where we've seen it with only minor variations in Camera2 implementation line numbers. All of the impacted devices are Android 11.