Status Update
Comments
mm...@commonsware.com <mm...@commonsware.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!
je...@gmail.com <je...@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
yb...@google.com <yb...@google.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?
mm...@commonsware.com <mm...@commonsware.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.
mm...@commonsware.com <mm...@commonsware.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.
de...@gmail.com <de...@gmail.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)
mm...@commonsware.com <mm...@commonsware.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).
de...@gmail.com <de...@gmail.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.
st...@gmail.com <st...@gmail.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)
}
}
}
st...@gmail.com <st...@gmail.com> #11
yb...@google.com <yb...@google.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.
st...@gmail.com <st...@gmail.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
sh...@gmail.com <sh...@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.
da...@google.com <da...@google.com>
ge...@gmail.com <ge...@gmail.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
ma...@marcardar.com <ma...@marcardar.com> #16
vi...@google.com <vi...@google.com> #17
mo...@gmail.com <mo...@gmail.com> #18
da...@google.com <da...@google.com> #19
sh...@gmail.com <sh...@gmail.com> #20
ap...@google.com <ap...@google.com> #21
Branch: androidx-master-dev
commit 54fa08a7bb20a88aa5266736d0183acc4dc66e89
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Sat May 25 16:14:28 2019
Use IF NOT EXISTS for Index create statement.
Bug: 62185732
Test: room:room-compiler:test
Change-Id: Ia58a4f4188425c2861cb14792b3e00ea83495bfb
M room/compiler/src/main/kotlin/androidx/room/vo/Index.kt
M room/compiler/src/test/kotlin/androidx/room/vo/IndexTest.kt
M room/integration-tests/kotlintestapp/schemas/androidx.room.integration.kotlintestapp.migration.MigrationDbKotlin/7.json
ap...@google.com <ap...@google.com> #22
Branch: androidx-master-dev
commit e70c2aa60c0c0324cf2ce9ed90d6847ac04cb789
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Sat May 25 16:37:56 2019
Create API for using Room with a pre-populated database.
The builder methods createFromAsset() and createFromFile() allows the
user to configure Room to use a pre-packaged database if the DB is being
opened for the first time ever. With fromAsset the DB file has to be
placed in the 'assets/' folder of the APK. With fromFile Room will try
to locate the file in external storage. As long as the right permissions
are available Room will be able to utilize the external storage path.
If the pre-packaged database file is an older version, then Room will
go through the upgrade flow as usual.
The pre-packaged database does not need to contain Room metadata table,
upon being opened Room will validate the schema and create it.
Bug: 62185732
Test: room:integration-tests:room-testapp:cC
Change-Id: I5d84a48f8511bcf3adaaaf6b8bf4073843f01ac7
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/IdentityDetectionTest.java
A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PrepackageTest.java
A room/integration-tests/testapp/src/main/assets/databases/products_badFile.db
A room/integration-tests/testapp/src/main/assets/databases/products_badSchema.db
A room/integration-tests/testapp/src/main/assets/databases/products_v0.db
A room/integration-tests/testapp/src/main/assets/databases/products_v0_badSchema.db
A room/integration-tests/testapp/src/main/assets/databases/products_v1.db
M room/runtime/api/2.2.0-alpha01.txt
M room/runtime/api/current.txt
M room/runtime/api/restricted_2.2.0-alpha01.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/DatabaseConfiguration.java
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
M room/runtime/src/main/java/androidx/room/RoomOpenHelper.java
A room/runtime/src/main/java/androidx/room/SQLiteCopyOpenHelper.java
A room/runtime/src/main/java/androidx/room/SQLiteCopyOpenHelperFactory.java
M room/testing/src/main/java/androidx/room/testing/MigrationTestHelper.java
ma...@marcardar.com <ma...@marcardar.com> #23
da...@google.com <da...@google.com> #24
ap...@google.com <ap...@google.com> #25
Branch: androidx-master-dev
commit 19fcda5e8d0af108b47c0f740bc7a82e02406131
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Fri May 31 15:04:57 2019
Use pre-populated DB on destructive migration.
When fallback to destructive migration is enabled and the database was
created using the createFromAsset or createFromFile APIs then try to
re-copy the pre-populated database when the database is being upgraded
and has no migration path.
Bug: 62185732
Test: room:integration-tests:room-testapp:cC
Change-Id: I2c6e56176c4feb3301790877c610ea7c5bf58b5e
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PrepackageTest.java
A room/integration-tests/testapp/src/main/assets/databases/products_v2.db
M room/runtime/api/restricted_2.2.0-alpha01.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
M room/runtime/src/main/java/androidx/room/SQLiteCopyOpenHelper.java
M room/runtime/src/main/java/androidx/room/SQLiteCopyOpenHelperFactory.java
M room/runtime/src/main/java/androidx/room/util/DBUtil.java
ap...@google.com <ap...@google.com> #26
Branch: androidx-master-dev
commit f0505b73efc88f23344e70fab11f347e8e00dc02
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Thu Jun 20 13:01:39 2019
Better error message for pre-package DB invalid schema.
Deprecate validateMigration in favor of onValidateSchema to be able to
perform schema validation in other cases other than migrations. The
new method returns a ValidationResult that indicates if the schema is
valid along with an expected-vs-found message to help fix the schema.
Caller then throws with appropriate message pointing to either migration
or pre-populate database validation.
Compatibility with already generate code that uses the the newer
RoomOpenHelper API is taken into consideration. Specifically, already
generate code don't need to implement new method since it has default
implementation. Meanwhile newly generated code doesn't have to override
old method since it has become non-abstract, an API binary compatible
change.
Test: Updated Tests
Bug: 62185732
Change-Id: If53a2a8a71826de4a1d9c97bd8f20796ea8eb594
M room/compiler/src/main/kotlin/androidx/room/ext/javapoet_ext.kt
M room/compiler/src/main/kotlin/androidx/room/writer/FtsTableInfoValidationWriter.kt
M room/compiler/src/main/kotlin/androidx/room/writer/SQLiteOpenHelperWriter.kt
M room/compiler/src/main/kotlin/androidx/room/writer/TableInfoValidationWriter.kt
M room/compiler/src/main/kotlin/androidx/room/writer/ViewInfoValidationWriter.kt
M room/compiler/src/test/data/databasewriter/output/ComplexDatabase.java
M room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/migration/MigrationKotlinTest.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/migration/MigrationTest.java
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PrepackageTest.java
M room/runtime/api/restricted_2.2.0-alpha01.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomOpenHelper.java
M room/testing/src/main/java/androidx/room/testing/MigrationTestHelper.java
ap...@google.com <ap...@google.com> #27
Branch: androidx-master-dev
commit 72b111275fd5df454834c026e45db9ec087c6b32
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Fri Jun 14 11:43:51 2019
Implement a copy lock mechanism for pre-populated databases.
Adds a two layer locking mechanism to protect the copy operation from
occurring concurrently within the same process or another process. The
idea is that the copy operation is lock protected and if there is
contention only one copy operation should occur.
Bug: 62185732
Bug: 135743327
Test: SQLiteCopyOpenHelperTest & PrepackageTest
Change-Id: I8013de92e83e016f0d3dec111e459ddac4a65513
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PrepackageTest.java
A room/integration-tests/testapp/src/main/assets/databases/products_big.db
M room/runtime/api/restricted_2.2.0-alpha01.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
M room/runtime/src/main/java/androidx/room/SQLiteCopyOpenHelper.java
A room/runtime/src/main/java/androidx/room/util/CopyLock.java
M room/runtime/src/main/java/androidx/room/util/DBUtil.java
A room/runtime/src/main/java/androidx/room/util/FileUtil.java
A room/runtime/src/test/java/androidx/room/SQLiteCopyOpenHelperTest.kt
Description
Version used: 1.0.0-alpha1
Devices/Android versions reproduced on: n/a
A common scenario is where an app needs to ship a database as part of the APK, or downloaded on first run of the app. That might serve as starter data, or it might serve as a read-only database of reference information. For the packaged-in-the-APK scenario, Jeff Gilfelt's SQLiteAssetHelper is a common solution, which replaces SQLiteOpenHelper and transparently copies the database from assets into the proper spot in the filesystem before proceeding.
With Room, there is no obvious way to handle the pre-populated database scenario.
One possibility is that Room doesn't do anything, and we have to arrange to get the database in position prior to creating the RoomDatabase. However, for that to work, we need to know where to put the database. While we supply the database name, technically Room could be storing that database anywhere (e.g., in a room/ subdirectory off of the normal database directory on internal storage). If we are going to go this route, we need some sort of documented statement about where Room stores the database, or a method to retrieve that location (prior to creating the RoomDatabase), so we know where to copy the database file into.
Other possibilities include:
- Having the option of subclassing the Framework implementation of SupportSQLiteOpenHelper, so we can craft a SQLiteAssetHelper-style implementation. Right now, that class is not part of the public API. While we could fork all of the Framework stuff to try to get this, that seems like overkill.
- Having a createFromAsset() and/or createFromFile() method on RoomDatabase.Builder, for us to provide the location of the starter database, for Room to copy into position for us if the database does not already exist.
Thanks!