Status Update
Comments
al...@google.com <al...@google.com>
ri...@google.com <ri...@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!
ri...@google.com <ri...@google.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
jo...@gmail.com <jo...@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?
pr...@google.com <pr...@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.
ki...@gmail.com <ki...@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.
se...@gmail.com <se...@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)
go...@google.com <go...@google.com>
ya...@gmail.com <ya...@gmail.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).
ly...@gmail.com <ly...@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.
sh...@gmail.com <sh...@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)
}
}
}
so...@gmail.com <so...@gmail.com> #11
ba...@gmail.com <ba...@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.
go...@google.com <go...@google.com>
po...@gmail.com <po...@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
ma...@zentity.com <ma...@zentity.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.
de...@workerbase.com <de...@workerbase.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
as...@google.com <as...@google.com> #16
as...@google.com <as...@google.com> #17
Hey all, we added text like this to the
For backward compatibility with previous Android versions, equivalent APIs are also available in AndroidX. However, the backward compatible APIs work with the AppCompatActivity context, not the application context, for Android 12 (API level 32) and earlier. Access the backward compatible APIs with Appcompat 1.6.0 or higher.
se...@gmail.com <se...@gmail.com> #18
I would suggest at least adding to the documentation about the attachBaseContext()
required in Application.kt, Services, activities that do not extend AppCompatActivity, etc. And a suggested implementation or gist would be very useful too.
This documentation could be added beneath, or as part of
Such as...
Application Context in Android 12 and lower
In order for application context to have the correct language resources, developers will need to handle attachBaseContext()
in Application.kt, Services, activities that do not extend AppCompatActivity (TODO: Where else is this needed???). The following code snippet shows how this may be implemented:
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(getContextForLanguage(base));
}
public static Context getContextForLanguage(Context context) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) return context;
String languageTag = PreferenceManager.getDefaultSharedPreferences(context).getString(PREF_APP_LANGUAGE_TAG, "");
if (languageTag.isEmpty()) return context;
Locale locale = Locale.forLanguageTag(languageTag);
Locale.setDefault(locale);
Resources resources = context.getResources();
Configuration configuration = resources.getConfiguration();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
configuration.setLocales(new LocaleList(locale));
} else {
configuration.setLocale(locale);
}
return context.createConfigurationContext(configuration);
}
I'm not sure if this is the best implementation, but it has worked very well for our app with ~5m downloads (and supported in 22 languages). I think many developers are avoiding adding an in-app language picker for Android 12 and under due to the amount of testing and lack of documentation that increases the risk trying to find the correct implementation.
Thanks!
do...@gmail.com <do...@gmail.com> #19
ch...@gmail.com <ch...@gmail.com> #20
I would also like to point out that when setting locale to Traditional Chinese for Android 6 (not tested on earlier Android versions from KitKat to Lollipop), the following codes do not work even for Activity Context:
AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale.TRADITIONAL_CHINESE))
AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale.TAIWAN))
AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale("zh", "TW")))
AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale("zh_tw")))
The following works for Android 6:
AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale("zh-tw")))
as...@google.com <as...@google.com> #21
Hi
ca...@google.com <ca...@google.com> #22
We added new API (
Feel free to try it and let us know if there is any issue.
Here is the release note:
se...@gmail.com <se...@gmail.com> #23
Thanks! I just tested this and works great... on a side-note Services also need this added in attachBaseContext()
otherwise they can have the wrong context for notifications, strings, etc.
I didn't see any issues with upgrading users who have already selected a different language either - their context/strings looked correct with Application context 👍
se...@gmail.com <se...@gmail.com> #24
One issue I've found with ContextCompat.getContextForLanguage()
is that it doesn't update the default Locale - Locale.getDefault()
.
This can prove problematic in Application/Service classes, as well as it isn't inline with the other changes with language changes in AppCompatActivity
or in API 33+, which both adjust the Locale.getDefault()
to the users selected language.
I believe the default Locale should be updated similarly as done in AppCompatActivity/API 33+, no?
ca...@google.com <ca...@google.com> #25
Hi,
Thanks for your feedback. I agree that adding Locale.getDefault()
to ContextCompat.getContextForLanguage()
would help some developers who are not aware that Locale
is still not updated in other Android components. However, it doesn't make much sense from an API perspective. If someone just wants to get the context via ContextCompat.getContextForLanguage()
, they may not be aware that an unrelated object (Locale
) has also been changed. It looks fine in per-app locales cases for now, but we don't want someone to use this API to cause unexpected behavior someday. I think we can add some description in the docs to help other developers aware this so that app owners can add Locale.setDefault()
themselves.
se...@gmail.com <se...@gmail.com> #26
Good point, it doesn't make sense to set the default Locale in ContextCompat.getContextForLanguage()
. When you update its docs can you state that the per-app locale can be retrieved with LocaleManagerCompat.getApplicationLocales() outside of activity context to set default Locale with?
Otherwise I think developers are going to try to use AppCompatDelegate.getApplicationLocales() and not know there's another similar API...
ca...@google.com <ca...@google.com> #27
Thanks, I'll update it in the docs. If you want to set per-app locale to Locale
after ContextCompat.getContextForLanguage()
, you can consider getting per-app locale from Context
, which returns from ContextCompat.getContextForLanguage()
because its configuration already contains per-app locale and you can save one disk IO.
se...@gmail.com <se...@gmail.com> #28
Right, using LocaleManagerCompat.getApplicationLocales()
would lead to an extra disk IO.
So, basically an in-app implementation of this could be...
Context updatedContext = ContextCompat.getContextForLanguage(initialContext);
Locale updatedLocale = updatedContext.getResources().getConfiguration().locale; // using deprecated for example only
// Avoid setting default locale needlessly
if (!Locale.getDefault().equals(updatedLocale)) {
Locale.setDefault(updatedLocale);
}
return updatedContext;
Thanks!
[Deleted User] <[Deleted User]> #29
Using ContextCompat.getContextForLanguage(context)
and setting the base context in the Application
works great for the use case when the app is restarted. The problem we have is when we update the locale programmatically in the app with AppCompatDelegate
.
We are using the application context to retrieve strings across the whole app.
How can we make sure that this application context is using the app locale under the hood without restarting the whole application?
se...@gmail.com <se...@gmail.com> #30
I just opened another issue for per-app languages (affects Android 12 and under too):
[Deleted User] <[Deleted User]> #31
E.g.
- The user has configured multi-profile and when the application is launched multi-profile screen displays there are 3 user logins and each has a different locale, once any user is selected related locale should be set. For activity, it is working correctly but with the application context below Android 12, it picks the device locale for the application context string.
- For the same scenario, if a user selects the first user and then navigates to the second user then the application locale should also be refreshed.
Please suggest a solution or way to fix it otherwise it is difficult to migrate.
sh...@miniclip.com <sh...@miniclip.com> #32
ch...@beyls.net <ch...@beyls.net> #33
The current implementation of ContextCompat.getContextForLanguage(context)
has some major issues that make it hard to recommend:
- Each call performs a blocking disk I/O call which impacts performance, because
LocaleManagerCompat.getApplicationLocales(context)
(used internally) performs a disk I/O.ContextCompat.getString(context, resId)
suffers from the same issue because it callsContextCompat.getContextForLanguage(context)
internally. - The documentation suggests to call it in Application's
attachBaseContext()
, in which case a single I/O call would be acceptable. However, if the selected language is updated while the application is open, the Application context language will not be updated, so this technique doesn't work properly.
I suggest to implement some synchronized caching mechanism in AppLocalesStorageHelper
, similar to what AppCompatDelegate
does. This way, there should only be a single blocking disk I/O during the first call to ContextCompat.getContextForLanguage(context)
, and it can then be called repeatedly everywhere an Activity Context is not available.
The documentation should also be updated to mention the big limitation of calling ContextCompat.getContextForLanguage(context)
in Application's attachBaseContext()
.
As a workaround, I reimplemented ContextCompat.getContextForLanguage(context)
to use a cache internally that I also update when calling AppCompatDelegate.setApplicationLocales()
, but since that cache is not synchronized with AppCompatDelegate
's cache I get 2 blocking I/O reads in total.
ch...@gmail.com <ch...@gmail.com> #34
Any updates on issue described in the comment above?
Description
Version used: 1.6.0-beta01
Devices/Android versions reproduced on: OnePlus 9 Pro Android 12
Setting locale via AppCompatDelegate.setApplicationLocales doesnt work with application context on Android 12. In Android 13 the following snippet is using the in app language for both rows but on Android 12 first row is printed in phone locale and second one in app locale.
Log.d(TAG, applicationContext.getString(R.string.settings_change_button)) // Application context
Log.d(TAG, getString(R.string.settings_change_button)) // Activity context