Status Update
No update yet.
Comments
ub...@gmail.com
This is with the latest CameraX 1.1.0-beta03.
ub...@gmail.com
Thanks for reporting the issue. We will look into the bug and update here soon.
ub...@gmail.com
Hi Shuzen
We've got this public issue from developers where querying CameraCharacteristics.CONTROL_ZOOM_RATIO_RANGE seems to cause crash on some cheap devices in India.
Is this because these cheap devices do not pass CTS ?
da...@google.com
Is it possible to get a bugreport from those devices?
ub...@gmail.com
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.
ub...@gmail.com
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.
da...@google.com
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
ub...@gmail.com
This crash looks similar to the one in
yb...@google.com
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?
ub...@gmail.com
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.
yb...@google.com
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
ub...@gmail.com
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...@google.com
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.
yb...@google.com
Thanks for the information, it seems match with the guess.
el...@google.com
ub...@gmail.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.camera:camera-camera2:1.2.0
ub...@gmail.com
I meant
yb...@google.com
are you still blocked on the SSH issue? FYI we do have other people sending PRs from Github without that issue so I would like to figure out what is broken in your case (as it might be affecting other people as well).
I want to respect your time though so if you don't want to deal with it anymore, you can send a PR without tests and we'll take it from there to add tests (though unfortunately, we cannot merge a PR without tests so we'll need to add them).
ub...@gmail.com
Thanks for your and Aurimas' help on the SSH issue last year, doing a checkout with filter and SSH caused the problems. I suggested updating the online instructions to point out this gotcha, not sure what happened after that on your end.
I am sending you a PR with the fix & added test. I gave it one more push to get if off my mind.
el...@google.com
ap...@google.com
Branch: androidx-main
commit a5c2900ca26e8f24d4492e5a0e90f0669702c680
Author: Uli Bubenheimer <bubenheimer@users.noreply.github.com>
Date: Mon Apr 19 09:22:25 2021
[GH] Fix intermittent InvalidationTracker issues in JournalMode.TRUNCATE
## Proposed Changes
- Fixes issue in Room JournalMode.TRUNCATE where the InvalidationTracker callback is sometimes invoked invalidly, too late, or not at all.
- Adds InvalidationTrackerBehavioralTest
## Testing
Test: ./gradlew test connectedCheck -x :room:room-benchmark:cC -x :room:integration-tests:room-incremental-annotation-processing:test
## Issues Fixed
Fixes:
This is an imported pull request from
Resolves #159
Github-Pr-Head-Sha: b32fc85dd1368db5fe046b1edfecdb82ac3e5478
GitOrigin-RevId: 169da50d9ce5d0be6aa686d603d51a380f46ab63
Change-Id: I0c04f25303043f45c8efe687df93f7122acbc7d4
A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/InvalidationTrackerBehavioralTest.java
M room/runtime/src/main/java/androidx/room/InvalidationTracker.java
Description
Component used: Room InvalidationTracker
Version used: 2.2.5
Devices/Android versions reproduced on: Android Studio emulator with Android R DP 2.1
Sample project:https://github.com/bubenheimer/invalidationtrackerbug
I am seeing consistency problems with the updates from InvalidationTracker when using JournalMode.TRUNCATE.
In my production app some updates are skipped - the observer is never called for a percentage of updates to a rarely updated table, causing the associated app screen to not get updated to the current state. I debugged into it and believe that this is associated with a lack of transactionality in InvalidationTracker.mRefreshRunnable. JournalMode.WRITE_AHEAD_LOGGING uses a transaction here, while JournalMode.TRUNCATE does not. Reads and writes of the table update log are disassociated, leaving the door open to overwriting recent changes to the log.
In the provided sample project I see the opposite effect, however: a lot of extra updates are triggered by InvalidationTracker with JournalMode.TRUNCATE. I am not sure what the underlying mechanism is for this behavior.
Exact effects are timing-related. The bottom line is that InvalidationTracker looks essentially broken for JournalMode.TRUNCATE. On the other hand I do not see significant issues with JournalMode.WRITE_AHEAD_LOGGING.