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