IssueTracker

this issue was created using original issue https://issuetracker.google.com/issues/389970341#comment2.

but i am not sure that described text above is the same as in original issue:

also doesn't work https://example.com/path/detail?token=123 in all versions.

pattern:

https://example.com/path/.*?token={id}

P.S. original issue also has test project https://issuetracker.google.com/389970341#attachment62385890

It's essentially the same cause - navigation is prioritizing the wrong deeplink when they share the same action.

Fixed internally and will be available in navigation-2.8.8

Project: platform/frameworks/support
Branch: androidx-main
Author: Clara Fok <clarafok@google.com>
Link:      https://android-review.googlesource.com/3490354

Fix deeplink incorrectly matching when deep link fields don’t match perfectly

Fix deeplink incorrectly matching when deep link fields don’t match perfectly 
 
Navigation used to allow matching as long as one of three (uri / action / mimType) matches. However this is erroneous, as each field is a defined filter - a potential match should at the very least fulfill all filters. 
 
This is fixed by applying these ground rules for deeplink matching: 
1. The added NavDeepLink field’s nullability has to match the NavDeepLinkRequest field’s nullability. i.e. if deeplink.uri is null, request.uri must also be null 
2. Any NavDeepLink non-null fields has to match exactly with NavDeepLinkRequest’s non-null fields 
 
To elaborate, consider this scenario where 
 
request: 
“www.example.com/13”, action = “theAction” 
 
potential matches: 
1. www.example.com/{id}, action = "theAction" 
2. www.differentUrl.com, action = "theAction" 
 
When handling this request , even though deeplink 2 has a matching action, the differing url will rule it out as a potential match. 
 
This fix also addresses a bug with wildcards where 
 
request: 
www.example.com/wildCardMatch?token=123, action = "theAction" 
 
potential matches: 
1. www.example.com/.*?token={id}, action = "theAction" 
2. www.example.com?token={id}, action = "theAction" 
 
Even though both deep links have a matching Action, deeplink 1 has a better Uri match, and so the request will now match with deeplink 1 instead of deeplink 2. 
 
Test: ./gradlew navigation:navigation-common:cC 
Test: ./gradlew navigation:navigation-runtime:cC 
Bug: 395712033 
Relnote: “NavDeepLink matching has been fixed where a deeplink and a deeplink request have to match exactly on uri, action, and mime. Matching is no longer allowed if only one or two fields match.“ 
Change-Id: I3b0295caa6324cc707d080856e88e62b4c3cd4d5

I think this fix has broken some other deeplinks.

I have the following defined in my NavHost file:

composable<Screen.AttractionDetail>(deepLinks = listOf(navDeepLink<Screen.AttractionDetail>(basePath = "gocity:/attraction"))) ...

@Serializable
data class AttractionDetail(val id: String, val hideBookmark: Boolean = false) : Screen

In one of my UI tests I have this code:

deeplinkNavigator("gocity:/attraction/$attractionId")

With 2.8.7 this works fine but as soon as I upgrade to 2.8.8 the deeplink no longer opens the AttractionDetail screen.

I've experimented with changing the data class to be val hideBookmark: Boolean? and to using uriPattern instead of basePath but I can't get this deeplink to work in 2.8.8

comment#6 I replicated your setup and the deeplink worked for me.

@Serializable
sealed interface Screen {
    @Serializable
    data class AttractionDetail(val id: String, val hideBookmark: Boolean = false) : Screen
}

controller.graph =
    controller.createGraph(startDestination = "start") {
        ...
        composable<Screen.AttractionDetail> { deepLink(navDeepLink<Screen.AttractionDetail>("gocity:/attraction")) }
    }

val request = NavDeepLinkRequest(Uri.parse("gocity:/attraction/13"), null, null)
val handled = controller.handleDeepLink(request)

Can you file a separate bug and attach a repro?

comment#6, comment#7

I also had problem after updating to version 2.8.8.

Explicitly setting action to Intent.ACTION_VIEW in the Deep Link builder now may be required if your intent filter for deeplink schema has android.intent.action.VIEW. At least that's how I solved the issue that I got after using version 2.8.8.

See example:

Manifest:

<intent-filter>
                <action android:name="android.intent.action.VIEW" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />
                <data
                    android:scheme="company"
                    android:host="app"
                    android:pathPattern="/.*" />
            </intent-filter>

In broadcast receiver:

//...
val deepLinkUri = NavDeepLinks.progressDeepLink.uriPattern
val intent = Intent(
            Intent.ACTION_VIEW,
            Uri.parse(deepLinkUri) //
        ).apply {
            flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP
            `package` = context.packageName
        }

        val pendingIntent = PendingIntent.getActivity(
            context,
            0,
            intent,
            PendingIntent.FLAG_IMMUTABLE
        )
//...

Definition of DeepLink using builder:

    val progressDeepLink = navDeepLink {
        uriPattern = "$BASE/${Path.PROGRESS}"
        action = Intent.ACTION_VIEW
    }

Compose Navigation Graph Builder:

navigation<LimitsDirection>(
                deepLinks = listOf(NavDeepLinks.limitsDeepLink)
            ) {
                    LimitsScreen(viewModel = limitsViewModel)
            }

I hope that helps you.

Also, may be this fix requires some update for documentation and/or guides

comment#7,comment#8 I created a bug for this with a simple project to reproduce it, and it was already a duplicate of another known bug in 2.8.8.

The bug fix for comment#6, comment#8 will be in 2.8.9.

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.