Status Update
No update yet.
Comments
il...@google.com
il...@google.com
ap...@google.com
This is with the latest CameraX 1.1.0-beta03.
ap...@google.com
Thanks for reporting the issue. We will look into the bug and update here soon.
ga...@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 ?
fo...@google.com
Is it possible to get a bugreport from those devices?
ap...@google.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.
ap...@google.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.
Description
When defining an explicit deep-link using NavDeepLinkBuilder, only a single Argument bundle can be provided for every Fragment destination inferred from XML. This can cause conflicts between arguments of the same name shared by different Destinations, and no argument verification is performed, so it's possible for parent Fragments to crash at navigateUp() time.
Request: A NavDeepLinkBuilder api that allows composition of explicit [destId, args] pairs to construct a destination stack. Preferably, accepting NavDirections as the parameter, so existing SafeArgs generated wrappers can be reused for argument safety.