Getting ready to distribute my first android-libra...

# squarelibraries

[Colton Idle]

Getting ready to distribute my first android-library, so I'm doing a final check.

If I'm using okhttp in my android library (as an implementation dependency) do I need to include keep rules in consumer-rules.pro and proguard-rules.pro?

Or since it's an android lib... will all of those proguard rules just work? I keep chasing my tail on this because I'm teetering on whether or not we will proguard our library so its a bit obfuscated (in the finance space so PM/TL really want obfuscation)

[trevjones]

they pre-pack rules in META-INF for okhttp so you should only need to write rules for your own code.

https://square.github.io/okhttp/features/r8_proguard/

If you end up running R8 on the library you will want two different rule sets sort of a super/sub pair of rules. One for you to run to protect the public api for the consumer to see, then the consumer rules would just be what can't be renamed for reflection purposes.

[Colton Idle]

The pre-packed rules get transferred down to android-libs too? I thought maybe that only happens when consumed from an android app.

[trevjones]

Pretty sure it will pick them up. once you start running it to test you can look in the build dir and the merged config that it uses should be in there to verify

[Colton Idle]

Thanks. enabling proguard to run on my library is definitely nervewracking. much more comfortable with it from the android app side of the equation.

[Colton Idle]

i think generally if my app is just making network calls with okhttp and deserializing with kotlinx.serialization... I don't believe I'll need to have any specific consumer.rules or my own proguard.rules.

[trevjones]

I've never done it but I expect you should be able to add both the consumer rule file + your rule file to the R8 task in your library. should keep the copy paste between the two at zero.

I've actually not used kotlinx much, I usually just stick with moshi, pretty sure the okio segment sharing in/out of retrofit/okhttp give it an edge on memory, but at this point its mostly because of familiarity.

[jw]

If you're only doing JSON you can use Okio with kotlinx.serialization

[jw]

The only rules you will need are keeping your public API entrypoints to ensure they don't get obfuscated away. You shouldn't need any consumer rules.

[Colton Idle]

If you're only doing JSON you can use Okio with kotlinx.serialization

Do you mean

"If you're only doing JSON you can use Okhttp with kotlinx.serialization"?

[jw]

No. So kotlinx.serialization generally deals in byte arrays (for binary formats) and strings (for text formats). However, there's a special variant of JSON which speaks Okio.

[Colton Idle]

gotcha. im guessing you're referring to this

https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-json-okio/kotlinx.serialization.json.okio/

[jw]

Yes. So if you happen to already be using Okio, you can pass it directly, without doing a buffering step first.

[Colton Idle]

🫡

[Colton Idle]

> The only rules you will need are keeping your public API entrypoints to ensure they don't get obfuscated away. You shouldn't need any consumer rules.
cool. i will double check why it seemed like i had to add rules.

i mostly wanted the sanity check if pre-baked proguard rules do indeed get passed into android-library as they do with android-application. 👌

[ursus]

Hmm about the kotlinx.serialization.okio

If I'm using ktor with okhttp as engine, do I get the optiimizations that were touted when everyone was okhttp+retrofit+moshi? (sharing buffers or something like that I believe)

[jw]

No

[jw]

Ktor has its own byte channel thing

[ursus]

shame,thanks!

[Colton Idle]

@jw one point of clarification

"The only rules you will need are keeping your public API entrypoints to ensure they don't get obfuscated away. You shouldn't need any consumer rules."

if i understand correctly:
if you do run proguard on your library... then you will need proguard.pro rules to maintain your public api entrypoints, but you shouldn't need consumer.pro rules

if you do not run proguard on your library... then you will not need proguard.pro rules or consumer.pro rules

[jw]

consumer rules are either always needed or always not needed regardless of whether you shrink your library

[jw]

and then whether you shrink the library is whether or not you need rules for your entrypoints

[Colton Idle]

makes sense to me! thanks for teaching