Document proguard rules

[swankjesse]

Our users are running into problems with java.nio.file.Path. We have proguard rules that help to work around this. We should document 'em.

See also #42

[JakeWharton]

Lint also apparently fails. Sigh.

OkHttp 2.0.0-RC1 - getting this lint error during the build process:

.gradle/caches/[...]/okio-1.0.0.jar:
Invalid package reference in library; not included in Android: java.nio.file.
Referenced from okio.Okio.

via square/okhttp#896

[rockerhieu]

Here is how I fixed the Lint error (actually is just a workaround):

  compile fileTree(dir: 'libs', include: ['*.jar'])
  compile('com.squareup.okhttp:okhttp-urlconnection:2.0.0') {
    exclude group: 'com.squareup.okhttp', module: 'okhttp'
  }
  compile('com.squareup.okhttp:okhttp:2.0.0') {
    exclude group: 'com.squareup.okio', module: 'okio'
  }

And with okio-1.0.0.jar inside libs folder, here is the lint configuration:

<lint>
  <issue id="InvalidPackage">
    <ignore path="libs/okio-1.0.0.jar"/>
  </issue>
</lint>

[ollie72]

I'm using Retrofit with OkHttp and I'm also seeing this. It's a shame as I like to maintain "lint zero". The okhttp exclude in the build.gradle method above gives me this at runtime: "java.lang.NoClassDefFoundError: com.squareup.okhttp.internal.http.RetryableSink" so I tried this in build.gradle

//noinspection InvalidPackage
compile ('com.squareup.okhttp:okhttp-urlconnection:2.0.0')
//noinspection InvalidPackage
compile ('com.squareup.okhttp:okhttp:2.0.0') { exclude group: 'com.squareup.okio', module: 'okio' } 

But that does not stop the lint error. I ended up adding it to lint.xml as a global rule which isn't ideal but does the job.

<issue id="InvalidPackage" severity="ignore" />

[tadfisher]

If you don't want to ignore InvalidPackage globally, this works as well:

<issue id="InvalidPackage">
    <ignore regexp="okio-1.0.0.jar" />
</issue>

[spengilley]

I too am suffering with this lint failure which adds an ugly red smear to my lint report :)

[crossle]

Same problem. +1

[VicV]

Just started getting this as of today. Haven't had this problem for months before.

[designatednerd]

If you're using Gradle, it's definitely a hacky solution, but you can completely disable the linting for invalid packages by adding:

    lintOptions {
        disable 'InvalidPackage'
    }

to your android closure at the app level, and then your app will at least build.

This should definitely get fixed at the okio level, though.

[JakeWharton]

Fixed how? There's nothing wrong with it.

[designatednerd]

Not being able to build without turning off linting for invalid packages means something is wrong. Maybe this is something that needs to get fixed in Gradle and not at your level - is there a way to specify at the repo or pom level that a certain package doesn't need to be checked for on Android?

[JakeWharton]

No. You can file a feature request for something like that on http://b.android.com though.

[designatednerd]

I will - is there any way to add documentation here or at the Retrofit level for this workaround on android since it is a known issue?

[VicV]

See, the problem I have is that even with proguard and linting rules, this problem still occurs in this situation:

Project A is main project in Android Studio

Module B is a module I have (a library) that for testing, is imported locally via this way in A's settings.gradle: project(':foo').projectDir = new File(settingsDir,'/path/to/module')

Then project A has this dependency: complile project(:foo)

---

If module B has okio dependencies, and I run a ./gradlew clean build from project A, as of 0.8.6 the errors will prevent the entire project from being build correctly. This was entirely untrue in the past (as my previous comment mentioned).

However I think this is an issue with the new proguard implementation of AS, given that proguard simply isn't ran on module B during this build step regardless of the settings.

So, in developing a library dependent on okio, its quite frustrating. But, it all works fine I suppose, I just have to build from the 'correct' locations now.

Merely an inconvenience, and nothing to 'fix'.

[JakeWharton]

At the very least this case should probably be a lint warning, not an error. Perhaps they're not interested in that granular of parsing for what is happening here.

In Okio's case, it's impossible to link against these methods in your code therefore it's impossible to cause harm to your application (unless you are using reflection and trying to invoke it).

[designatednerd]

I certainly agree that I would expect this to be a warning, not an error. But for right now, this is getting recognized by gradlew lint as an error.

It would be helpful to have a documented workaround if this is an issue out of control of the okio/Square team.

[monxalo]

Rather than disabling the lint check you can change its severity.

lintOptions {
   warning 'InvalidPackage'
}

This way it will still show up in lint results with a warning.

[Macarse]

<issue id="InvalidPackage" severity="error">
        <ignore regexp="okio.*jar" />
</issue>

to keep it as an error and ignore okio's jar file.

[3flex]

Closed by #275?

Regarding Android lint, seems #58 (comment) is the best workaround as it disables the error only for this lib. Could this be added to the README?

[noamtamim]

Is there a plan to fix the lint part of this issue? You may consider offering a separate build of the library for Android, that doesn't contain the non-Android java.nio.file.Path class.

[JakeWharton]

No. Android O will have this class anyway.

…

On Sun, Mar 19, 2017, 6:31 PM Noam Tamim ***@***.***> wrote: Is there a plan to fix the *lint* part of this issue? You may consider offering a separate build of the library for Android, that doesn't contain the non-Android java.nio.file.Path class. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEfUz2nW1Luuh7J-bk-mVXfXKrI70ks5rnayjgaJpZM4B_2u1> .

[jaredsburrows]

I tried to do this here: #268.

[swankjesse]

We have a ProGuard section on our main readme now.