Status Update
Comments
ba...@gmail.com <ba...@gmail.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!
yc...@gmail.com <yc...@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
ri...@gmail.com <ri...@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?
yu...@gmail.com <yu...@gmail.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.
st...@detroitlabs.com <st...@detroitlabs.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.
na...@gmail.com <na...@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)
ri...@gmail.com <ri...@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).
sk...@gmail.com <sk...@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.
sk...@gmail.com <sk...@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)
}
}
}
sk...@gmail.com <sk...@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.
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
dn...@google.com <dn...@google.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.
st...@gmail.com <st...@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
gk...@gmail.com <gk...@gmail.com> #16
m4...@gmail.com <m4...@gmail.com> #17
dg...@gmail.com <dg...@gmail.com> #18
Should we use one of the workarounds posted here?
il...@google.com <il...@google.com> #19
While we can't fix the general case here within an unbundled library like Fragments, we can fix this in cases where the parent layout is a FrameLayout / extends FrameLayout by delaying the removal of the old View until after the animation completes under the assuption that children of a FrameLayout are suitably independent that animating one in while the other still exists in the layout is not an issue.
This should at least fix the issue for libraries built on top of Fragments such as Navigation.
[Deleted User] <[Deleted User]> #21
dc...@gmail.com <dc...@gmail.com> #22
ga...@gmail.com <ga...@gmail.com> #23
Ignore the fact that this library is a React Native library, it works the same for native apps.
ki...@gmail.com <ki...@gmail.com> #24
I've made a custom view group based on ScreenCoordinatorLayout
In bug case, Fragment.animateRemoveFragment() is called, but
ja...@planticle.com.au <ja...@planticle.com.au> #25
Still, this is was a frustrating and time consuming bug to work around, and I look forward to seeing a fix for this in the Jetpack Navigation library.
mi...@gmail.com <mi...@gmail.com> #26
We probably need to stick to activities if we want to follow material design guidelines.
I also look forward for this being fixed.
mi...@gmail.com <mi...@gmail.com> #27
mi...@gmail.com <mi...@gmail.com> #28
With the Navigation Component, and because of this limitation, is impossible to have an "slide on top" kind of transition.
ni...@webwag.com <ni...@webwag.com> #29
Currently, it's a FrameLayout which has this issue.
From NavHostFragment.java :
@Nullable
@Override
public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container,
@Nullable Bundle savedInstanceState) {
FrameLayout frameLayout = new FrameLayout(inflater.getContext());
// When added via XML, this has no effect (since this FrameLayout is given the ID
// automatically), but this ensures that the View exists as part of this Fragment's View
// hierarchy in cases where the NavHostFragment is added programmatically as is required
// for child fragment transactions
frameLayout.setId(getId());
return frameLayout;
}
je...@gmail.com <je...@gmail.com> #30
pe...@gmail.com <pe...@gmail.com> #31
Here may be a solution:
jb...@google.com <jb...@google.com>
ap...@google.com <ap...@google.com> #32
Branch: androidx-master-dev
commit 2534c731cc31a615e4584d74327521ec8c5a8aa7
Author: jbwoods <jbwoods@google.com>
Date: Thu Jun 20 12:42:37 2019
Draw exit animations first in FragmentContainerView
ViewGroups always draw exiting view animations last. For Fragments, this
means that the exiting Fragment is always on top of all others. There
can be no interaction with entering fragments, and there is the
possiblity of a "pop" when the exit animation finishes to reveal the
Fragment underneath.
FragmentContainerView overrides the dispatchDraw and drawChild method to
force all disappearing children to be drawn first. It overrides public
methods from ViewGroup to build the proper list of transitioning views
and disappearing child views.
Test: Added units tests, tested visually in app, ./gradlew checkApi
BUG: 37036000
Change-Id: I054eaf4ae234258bc7abec22c4c8e559a2c6be71
M fragment/fragment/api/1.2.0-alpha01.txt
M fragment/fragment/api/current.txt
M fragment/fragment/api/restricted_1.2.0-alpha01.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerViewTest.kt
M fragment/fragment/src/androidTest/res/layout/fragment_container_view.xml
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentContainerView.java
ge...@gmail.com <ge...@gmail.com> #33
[Deleted User] <[Deleted User]> #34
1. When going forward, I want exit animation to be bottom, and enter animation on top
2. When going backwards, I want exit animation on top, and enter animation on the bottom.
That way I could replicate iOS animation behavior where new fragment "comes on top" on previous, but when click back, I also want that fragment to disappear "from the top" and reveal previous fragment beneath it. android:zAdjustment sounds like something that should fix this problem, but is it working for Fragments and Navigation library?
Can anybody help me here?
il...@google.com <il...@google.com> #35
il...@google.com <il...@google.com>
bi...@gmail.com <bi...@gmail.com> #36
or...@gmail.com <or...@gmail.com> #37
"Fragments using exit animations are drawn before all others for FragmentContainerView. This ensures that exiting Fragments do not appear on top of the view."
Is our long national nightmare of improperly drawn transition animations over?
mo...@gmail.com <mo...@gmail.com> #38
^ This. I think ideally we should have a way of telling the Fragment its Z ordering during the animation. I know that are ways, but couldn't find any that works with the Navigation Components.
ma...@gmail.com <ma...@gmail.com> #39
I am experiencing the same issue for version 1.2.3 when using the "FragmentContainerView" and setting "EnterTransition" to a slide transition, and using an exisiting fade transition in "ExitTransition"?
So I am not using "FragmentTransaction.setCustomAnimations", but I guess it is supposed to work the same way?
[Deleted User] <[Deleted User]> #40
- works with setCustomAninations
- still does not work with setExitTransition / setEnterTransition
It looks like FragmentContainerView.startViewTransition is not called properly in the broken case, which causes that FragmentContainerView falls into the standard drawing path.
[Deleted User] <[Deleted User]> #41
The actual problem with setExitTransition / setEnterTransition is caused by fact that any subclass of Visibility transition (e.g. Fade, Slide, etc.), uses ViewOverlay to realize the animation when the exiting View is removed from its parent. And this is actually happening when performing replace() Fragment transaction. The trouble is than the entering view wont use ViewOverlay and will be effectively BELOW the exiting view :(
It is very sad that such basic usecases are still broken :(
I really cant believe that it was not catched earlier :(
As a workaround, one may try to write customized FragmentContainerVIew (cant inherit, because the one from Jetpack is final.... ) and write a customized set of Transitions that does not use ViewOverlay or use it in consistent manner preserving the z-order.
gc...@neptuneretailsolutions.com <gc...@neptuneretailsolutions.com> #42
Problem not fixed for Translations - suggest reopening.
My fix to allow enterTransition to act as if Hold() was working correctly. I don't enterTransition animate at all:
exitTransition = HoldBackground(resources).setDuration(duration)
enterTransition = Slide(Gravity.RIGHT).setDuration(duration)
With HoldBackground looking like this:
class HoldBackground(val resources : Resources) : Transition() {
init {
duration = resources.getInteger(android.R.integer.config_mediumAnimTime).toLong()
}
var inProgress = false
@Synchronized
override fun captureStartValues(transitionValues: TransitionValues) {
if(inProgress) return
transitionValues.view.also { exitingView ->
exitingView.parent.also { fragmentContainer ->
if(fragmentContainer is View && exitingView.width > 0 && exitingView.height > 0) {
inProgress = true
val previousBackground = fragmentContainer.background
val bitmap = Bitmap.createBitmap(
exitingView.width,
exitingView.height,
Bitmap.Config.ARGB_8888
)
exitingView.draw(Canvas(bitmap))
fragmentContainer.background = BitmapDrawable(resources, bitmap)
// Simple animator so timing matches developer animation scales
val animator = ValueAnimator.ofInt(0, 1).setDuration(duration)
animator.addListener(object : BlankAnimatorListener() {
override fun onAnimationEnd(animation: Animator?) {
fragmentContainer.background = previousBackground
inProgress = false
}
})
animator.start()
}
}
}
}
override fun captureEndValues(transitionValues: TransitionValues) {}
}
It's very likely stupidly resource intensive given it's creating a screen size bitmap... but it does happen to work.
yo...@gmail.com <yo...@gmail.com> #43
- Cancelling replace-fragment transitions, i.e. navigating up during a transition, causes the pop-exiting fragment to appear below the pop-entering fragment.
- It doesn't work with setExitTransition / setEnterTransition. Entering fragment is below the exiting fragment.
I have no words for this. Ill probably just use multiple-activities (instead of single-activity) and use activity transitions.
If someone has a solution, it will be much appreciated.
Description
ft.setCustomAnimations(R.anim.slide_in_right, R.anim.slide_out_left);
slide_in_right.xml
<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="
android:shareInterpolator="true"
android:interpolator="@android:anim/decelerate_interpolator">
<translate android:fromXDelta="100%"
android:toXDelta="0%" android:fromYDelta="0%"
android:toYDelta="0%" android:duration="400">
</translate>
</set>
anim.slide_out_left.xml
<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="
android:shareInterpolator="true"
android:interpolator="@android:anim/decelerate_interpolator"
android:zAdjustment="bottom">
<translate android:fromXDelta="0%"
android:toXDelta="-50%" android:fromYDelta="0%"<!-- -50% shows the problem, 100% does not -->
android:toYDelta="0%" android:duration="400">
</translate>
</set>
(The zAdjustment tag does nothing)
The exiting fragment will be on top of the entering fragment, which is the opposite behavior than what is expected or useful. Currently, an exiting fragment must leave the frame completely, otherwise it will be on top of the entering fragment at the end of the animation, at which point in the last frame of the animation the exiting fragment will pop out of existence. The Z order of the fragments should be reversed or made customizable. The current z ordering offers no advantages.
I am trying to achieve the material effect of putting one "page" of a fragment on top of another while moving the exiting "page" somewhat to the left (50%), rather than 100% which would give the effect of just shoving the exiting "page" to the left, not putting it under the entering fragment. There are some work arounds described here
but they don't apply to my case.