Status Update
Comments
rm...@google.com <rm...@google.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
fl...@gmail.com <fl...@gmail.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
fl...@gmail.com <fl...@gmail.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
rm...@google.com <rm...@google.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
fl...@gmail.com <fl...@gmail.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
br...@capitalone.com <br...@capitalone.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
tn...@google.com <tn...@google.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
tn...@google.com <tn...@google.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
br...@capitalone.com <br...@capitalone.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
tn...@google.com <tn...@google.com> #11
dy...@gmail.com <dy...@gmail.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
tn...@google.com <tn...@google.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
dy...@gmail.com <dy...@gmail.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
tn...@google.com <tn...@google.com> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
dy...@gmail.com <dy...@gmail.com> #16
br...@capitalone.com <br...@capitalone.com> #17
Because of our build system and how large our project is, I think it would be extremely difficult to reproduce in a sample project that I could share. However, I just ran into the issue with `NewApi` and `ObsoleteSdkInt` (as well as `ObjectAnimatorBinding` which is another one we see often, but let's stick to discussing the API-related rules, as I suspect we see these all pop up this way for the same reason).
Our project is, by default, set up so that every module aside from app modules are in binary form. To work on the source, we set a flag on that dependency which tells our build system to compile that module as source. When changes are ready to be merged, CI gathers all feature branches with the same name across all our modules, builds all the changed modules AND modules that can/will be impacted by these changes (based on a dependency tree analysis) from source, and runs a series of checks (including lint) on all modules in the workspace (any modules that are not impacted by the changes and are not changed themselves are dropped from the workspace).
Here is where the problem seems to start: A change is made to Module A. This change goes through CI, lint passes and everything seems to be OK. Later on, I go to update the module that contains our custom lint rules. Because ALL of our modules rely on this custom lint rules module, ALL modules are then built from source and checked. On that execution, we see lint errors thrown in Module A (the module that previously passed lint). When I have all modules set to binary and run lint on module A as source, there are no errors thrown. I'm able to reproduce this locally as well as on CI.
Here is the exact scenario we have run into today:
Module A contains a method `foo(...)` which is a public function and is called from module B. This public function then calls a private function that has this code
```
return if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.M) {
... <-- Code that tries to use `RecentTaskInfo#topActivity`
} else {
...
}
```
Again, when this module gets lint run on it by itself (all other modules in binary form), no error is produced. When ALL modules are built from SOURCE, we see:
src/main/java/example/MyClass.kt:48: Error: Field requires API level 23 (current min is 21): android.app.ActivityManager.RecentTaskInfo#topActivity [NewApi]
and
Error: Unnecessary; SDK_INT is never < 21 [ObsoleteSdkInt]
return if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.M)
Both of these errors don't make sense when applied to the code above because the gate check does ensure the call is made only on API 23 and ...the ObsoleteSdkInt error just doesn't make sense in general. :)
This behavior actually seems to be opposite of what you explained in
To recap, we DO see the error only when all modules (including module A) are included as source, but we do NOT see the error when all modules (except module A) are included as binaries.
I'm hoping something in this brain dump will flag something in your mind that might help us get to the bottom of this. Literally ANY point in the right direction is super appreciated.
tn...@google.com <tn...@google.com> #18
Hi there, Dylan sent me steps to reproduce, and with that I was able to check in a fix (for 4.1 and 4.0) yesterday.
The root problem in his scenario is that there are cases where resolving a method call fails -- and that was happening in that particular scenario. That meant lint didn't get a chance to look at the method at all, to see if it's a version check. My fix was to more gracefully handle that, such that it now will still look at the method name and call the method name check even if it cannot find the associated method. So if the method is for example called "isAtLeastQ", it will from that conclude that the API level is at least 29 if that method returns true.
This all sounds different from your problem Brandon. The most likely explanation is the same: that somehow resolving the method calls is failing. The most common reason for that is a classpath setup. It's hard to say more without knowing how the build sets up your source build...
br...@capitalone.com <br...@capitalone.com> #19
tn...@google.com <tn...@google.com> #20
Started work on this in the form of a new annotation you can annotate custom API method checks (and fields and properties with) to teach lint that a given method represents an API constraint:
(not yet ready to use; that annotation hasn't been released and lint doesn't know about it yet, but if you have thoughts on how it would work and how you would annotate your own API version utilities with it, speak up. See the javadoc for examples.)
tn...@google.com <tn...@google.com> #21
I forgot to close this bug but this was fixed quite a while back -- Studio 4.2 and probably Studio 4.1 at least understand the new annotation -- but in 7.0 it will (a) automatically handle local binary dependencies (e.g. in your own libraries that lint runs on, it will recognize these API checks and make a note for itself which it uses downstream, and (b) can suggest actually annotating these methods such that other uses of the library can automatically see the inference as well.
Description
Strange issue with Lint indicating false positives on API errors (NewApi, InlinedApi or ObsoleteSdkInt) when not using directly Build.VERSION_CODES constants.
It's broken since AGP 3.3.0, worked with AGP 3.2.1 and previous versions.
Example:
```
object AndroidVersions {
const val API_28 = Build.VERSION_CODES.P
private val infoFlag: Int =
if (Build.VERSION.SDK_INT >= API_28)
PackageManager.GET_SIGNING_CERTIFICATES
else
PackageManager.GET_SIGNATURES
```
Lint report the following warning: `Warning: Unnecessary; SDK_INT is never < 21 [ObsoleteSdkInt]` which has nothing to do here.
If we wrap the condition into a method, it produces a wrong InlinedApi warning:
````
object AndroidVersions {
const val API_28 = Build.VERSION_CODES.P
inline fun hasApi28() = Build.VERSION.SDK_INT >= API_28
private val infoFlag: Int =
if (AndroidVersions.hasApi28())
PackageManager.GET_SIGNING_CERTIFICATES
else
PackageManager.GET_SIGNATURES
}
Produces `Warning: Field requires API level 28 (current min is 21): android.content.pm.PackageManager#GET_SIGNING_CERTIFICATES [InlinedApi]`
When calling a method that requires an higher API level than min SDK using this method it produces an NewApi error.
```
Configuration:
Android Studio 3.3 RC 1
Build #AI-182.5107.16.33.5138683, built on November 19, 2018
JRE: 1.8.0_152-release-1248-b01 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.1