IssueTracker

Would it be possible to add a NavDirections overload to NavDeepLinkBuilder for this? It has both the id and the args so it's a nice way to add destination. I can also create an extra ticket.

Currently deep links always start with the nav_graph's startDestination. This is a problem for apps which use multiple root-level destinations in a bottom-navigation view, and unexpected for explicitly created synthetic task stacks using only addDestination().

I'm using an invocation like: navDeeplinkBuilder.addDestinaton(frag_two).addDestination(frag_three), where start_destination = frag_one. Using an initial setDestination doesn't seem to change anything. frag_one is always at the bottom of the back stack, with two and three above.

After building the deep link, I can see the first R.id is always 0 (or the android:id of the nav_graph, if you remembered to set one), as a result of NavDeepLinkBuilder's node.buildDeepLinkIds(prevdestination)

When navController receives the deep link, it will attempt to navigate to 0 (the navGraph itself), which NavGraphNavigator always substitutes with the startDestination.

Separately, the navGraph will be explicitly added above it as the parent of that startDestination using the mGraph id set on the end Fragment. link

So it seems like both NavDeepLinkBuilder and NavController are attempting to set the mGraph to the bottom of the task stack. I think the initial navGraph should just be implicit in the NavDeepLinkBuilder-created Intent, since there's already a stated dependency on the navGraph being the same at Intent-build-time and when the deep link is executed.

There's another curiosity here: Some 'unsigned rational' tags are returned from getAttribute(String) in the form "x/y", e.g. TAG_FOCAL_LENGTH. I dug a bit into this, and I think the 'automatically convert to floating point' behaviour was originally introduced in the framework version of ExifInterface (which existed before the AndroidX one was forked from it) as part of this commit in 2016. It looks like the concern then (as now) was maintaining compatibility with apps expecting the decimal format. There's a bit more context in this internal-only code review comment.

Given the constraint of maintaining this lossy format going forward:

ExifInterface already has 'different type' getAttributeXXX(...) 'overloads' like getAttributeInt(...). Given these already exist, we could consider adding add a @Nullable String getAttributeRational(String) that returns the "x/y" format for tags with TYPE = (Unsigned) rational. People would have to know to use it instead of getAttribute(String), but it at least gives 'lossless' access to the actual tag data read from the file - even for rational tags that are converted to lossy decimal/floating-point representations for backwards-compatibility..

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

• androidx.exifinterface:exifinterface:1.4.0-alpha01