IssueTracker

So there does seem to be a bug in Navigation that causes this to fail.

When it navigates with popUpTo and removes SecondFragment, that removal in fragment is set for a frame later and before it is actually removed the navigate call in the onViewCreated of SecondFragment enqueues another call to add it back. But we still need to destroy SecondDetailFragment which ends up marking the NavBackStackEntry associated with SecondFragment as complete before navigation has received the call from the fragment that it has been added back. So by the time it hits this check, the SecondFragment is in the correct state, but Navigation has no way of referencing it so it assumes that it is not associated with an entry.

But this is not the way this type of situation should be implemented. Instead of having the destinations as part of the NavGraph, they should:

1. be managed by the childFragmentManager of SecondFragment. So instead of going back to SecondFragment just to go somewhere else, each of the fragments take the entire content of SecondFragment and are swapped out.
2. for some sort of a/b testing, set different graphs in the Activity. The graphs would keep the same SecondFragment id, but swap out the names and then you choose the correct graph based on the condition.

1. Have SecondFragment as part of your graph and then inside of SecondFragment call the childFragmentManager and replace with the fragment you actually want to show, whether that is SecondTypeOne or SecondTypeTwo.
2. Create different graphs and follow along with the docs on using different graphs dynamically and inflate and set the one needed based on logic in your Activity.

Is there a planned fix for this issue? We've been stuck on Navigation 2.5.3 for some time due to issues in 2.6.x and now this issue, and the suggested workaround of restructuring our navigation graph is a pretty big lift. If that's the only recommended path it would be helpful to know so we can try to plan for that work, otherwise we'd want to just wait for the fix that doesn't require restructuring.

This was fixed by https://issuetracker.google.com/301887045 and will be available in the Navigation 2.7.4 release. We are also adding a regression test for this particular case.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.navigation:navigation-fragment:2.8.0-alpha01

Hello.

2. 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)
        }
      }
    }

I tried to find the device specs and both Fujitsu arrows Be F-05J and Fujitsu arrows M04 should have 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 aosp/1254406 that was merged in 2020/05/17 and should be included in 1.0.0-beta04 release. Before aosp/1254406 was merged, the only 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-rc01 version has been released. There should be many fixes included in it compared to the 1.0.0-beta04 version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01 version for your application. Thanks.

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 Fujitsu F-03K.

• 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

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.

The solution has been merged in https://android-review.googlesource.com/1545624. Update the status to be fixed.