The recommended substitute for clearTask of popUpTo with popUpToInclusive only works from start destination actions [116831650]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Sep 28, 2018 10:32AM

I was previously using clearTask in my navigation actions to make sure that the user could not navigate back to the previous destination (useful for splash screens and login screens). After it was deprecated I decided to try the recommended approach of instead setting popUpTo pointing to the root of the graph together with setting popUpToInclusive="true", but this didn't have the effect I wanted.

This approach only seem to work on actions originating from the graph's start destination, and fails on actions between any other destinations. I created a sample project which reproduces the issue:

https://github.com/hsson/android-navigation-component-alpha06-bug

Here is the project's README detailing the issue:

# Bug in Android Navigation Component (alpha06)
(Note: I have only verified this in alpha06, I don't know if it exists in
previous versions)

## The problem
Basically the problem is that the NavOption "clearTask" was removed in
alpha02, and the recommended substitute was to use app:popUpTo pointing to
the root of the graph/the graph ID, together with app:popUpToInclusive="true".
However, this method does not work. It only seems to work for actions
going from the graph's start destination. If we have the following graph:

x y
A ---> B ---> C

Where A, B, and C are fragments, A is the start destination of the grapg,
and x, y are actions going from A to B and B to C respectively. Let's say
the graph's ID is "@+id/graph"

Then, if both actions x and y have
app:popUpTo="@+id/graph"
app:popUpToInclusive="true"

Then when navigating from A to B through x, and then hitting the back button
will exit the app (as expected). But if navigating from A to B to C through
x and y, and then hitting the back button we will navigate back to B — this
is not what was expected. The expected behavior with this graph is to always
exit the app when clicking the back button

## Environment
This was verified using:
Android Studio 3.2 RC 3
Build #AI-181.5540.7.32.4987877, built on August 31, 2018
JRE: 1.8.0_152-release-1136-b06 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6

Comments

[Deleted User] <[Deleted User]> #2Oct 1, 2018 08:14AM

I don't think #1 makes a lot of sense. There are already potentially libraries out there without that metadata.

#2 makes the most sense to me, but in case we cannot be 100% reliable we should allow blacklisting libraries as described in #3. This should probably be handled globally for a project (in gradle.properpies rather than in the DSL)

il...@google.com <il...@google.com> Oct 1, 2018 10:56PM

Assigned to il...@google.com.

[Deleted User] <[Deleted User]> #3Oct 10, 2018 09:20AM

As I have mentioned I don't think there is a silver bullet. #2 does not work on 100% and #1 will take time before devs will provide the metadata. #3 is in my opinion very important to introduce asap, as the developers have no way how to workaround it at this stage. Also in the future there can be any other issue and there is nothing wrong in doing #3 until we figure out something robust (or for instance finally migrate work manager and navigation to androidx that would make #2 a feasible solution).

il...@google.com <il...@google.com> #4Oct 18, 2018 06:05PM

Yes, I'm working on #3 right now to unblock users. We can continue thinking about #2.

[Deleted User] <[Deleted User]> #5Oct 19, 2018 11:44AM

Starting with AGP 3.3.0-rc01 and 3.4.0-alpha04, to blacklist libraries that should not be jetified, users can add a comma-separated list of regular expressions to the following property in the gradle.properties file:
android.jetifier.blacklist = ...

If a library's absolute path contains a substring that matches one of the regular expressions, the library won't be jetified.

For example, if the property is
android.jetifier.blacklist = doNot.*\\.jar, foo
then "/path/to/doNotJetify.jar" won't be jetified.

Change-Id: I6531fe0faafa45dc2811c5223ba199ccce5fee53

Note that this is only a temporary workaround while we work on a proper solution.

mi...@gmail.com <mi...@gmail.com> #6Oct 19, 2018 12:22PM

Hi. I'm trying to use the `android.jetifier.blacklist` workaround to prevent jetify from processing lombok (which generates a DuplicateEntry exception when trying to transform). I can't see to get it working though. Here are the relevant files:

gradle.properties:
```
android.enableJetifier=true
android.jetifier.blacklist = .*lombok.*
android.useAndroidX=true
```

build.gradle:
```
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build.jetifier:jetifier-processor:1.0.0-beta02'
classpath 'com.android.tools.build:gradle:3.3.0-beta03'
}
}

plugins {
id 'com.android.application' //version '3.3.0-beta03'
id 'jacoco'
}
```

[Deleted User] <[Deleted User]> #7Oct 19, 2018 12:24PM

As mentioned at

comment #5

, you will need to use AGP 3.3.0-rc01+ or 3.4.0-alpha04+ for the workaround to take effect.

il...@google.com <il...@google.com> #8Oct 19, 2018 03:36PM

I am interested in the ability to blacklist dependencies from being jettified as well. The binary rewrite messes with AspectJ aspect classes. It re-introduces this problem:

https://issuetracker.google.com/issues/119153999

mi...@gmail.com <mi...@gmail.com> #9Oct 19, 2018 03:50PM

I've succesfully tested the blacklist config with:
* AGP 3.3.0-rc01
* Gradle 5.1-rc-1

I just wanted to add a comment about what I had to blacklist, so that perhaps jetifier can handle this automatically without a rule.

TL;DR: jetifier should probably not even try to open *.so files.

Details:
My project depends (transitively) on a jar which contains only native *.so files.
On one particular machine (docker container) with apparently not enough memory, I was getting this error:

Execution failed for task ':libon-lite-client:checkDebugClasspath'.
> Could not resolve all files for configuration ':libon-lite-client:debugCompileClasspath'.
> Failed to transform artifact 'liblinphone-debug-symbols.jar (org.liblinphone:liblinphone:4.0.1)' to match attributes {artifactType=android-classes, org.gradle.usage=java-runtime-jars}
> Execution failed for JetifyTransform: /root/.gradle/caches/modules-2/files-2.1/org.liblinphone/liblinphone/4.0.1/871c6e76e93a7fa1bbafb5eb450e45c2330e866/liblinphone-4.0.1-debug-symbols.jar.
> Java heap space

(Note that with gradle 4.10.2/AGP 3.2.1, I didn't have this detailed info, but just simply "Transformation hasn’t been executed yet" (

https://issuetracker.google.com/issues/119951660). I got this additional error message with gradle 5.1-rc-1/AGP 3.2.1.)

Now with gradle 5.1-rc1/AGP-3.3.0-rc01, I have this rule:
android.jetifier.blacklist=liblinphone-4.0.1-debug-symbols.jar

And I no longer get the error.

I suppose jetifier shouldn't even try to look into binary *.so files.

il...@google.com <il...@google.com> #10Oct 19, 2018 04:13PM

#comment9

:
Jetifier ignores *.so files. However it has to extract each archive to the memory and check each file and recreate a new zip file to the filesystem. So loading the archive to the memory has to be done no matter if there are .so files or not.

mi...@gmail.com <mi...@gmail.com> #11Oct 19, 2018 04:16PM

@Filip: I wonder if Jetifier should check the zip entries' meta data first (without loading their contents) and return immediately if there are no entries that need jetifying. (Returning is good enough, Jetifier doesn't need to copy the file to somewhere else. And even when it needs to copy some large entries from one zip file to another, we can probably use streams/Zip64 so that it doesn't load the entire zip file/zip entry into memory---see

Issue 113559507

dc...@gmail.com <dc...@gmail.com> #12Oct 23, 2018 05:19PM

Is anyone else having issues with AGP 3.3.0-rc01+ or 3.4.0-alpha04+ where the project compiles and runs fine, but cannot resolve the R file? I tried invalidating android studio caches, cleaning, deleting .idea, deleting .gradle, and nothing works except reverting to android plugin 3.2.1...which I can't do because I need the jetifier blacklist workaround.

da...@gmail.com <da...@gmail.com> #13Oct 26, 2018 10:58PM

@12 Sounds like a different issue, possibly around light R classes handling in the IDE, would you mind filing a bug for it and describing the problem in more detail or provide a repro project?

il...@google.com <il...@google.com> #14Nov 30, 2018 11:21PM

Marked as fixed.

It seems to be working fine in Android Studio 3.3 so I think it might not be an issue in the future. Thanks for the response!