[aerogear-dev] Android Dependencies and DEX Size

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] Android Dependencies and DEX Size

Artur Dryomov
Hi everyone,

So, I’ve just hit the famous 65 K methods count and DEX error as a sweet bonus while updating the application to latest Android 6.0-related dependencies.

Long story short, I’ve analyzed [1] dependencies [2] for the Hawkular Android Client [3]. Important notice—the application is not that big or complicated.

Methods count is below.
  • Various dependencies: 2445.
  • Java & JavaX: 1684.
  • Android Support libraries: 12988.
  • Android: 3081.
  • Google Play Services: 22022.
  • Bouncycastle: 10423.
  • Spongycastle: 10423.
  • AeroGear: 1210.
  • Application itself: 1047.
  • Total: 65346.
This is kind of disappointing. Of course I can start to blame Android Support libraries, but you clearly cannot develop apps these days without using backports and helpers. Google Play Services is a bigger deal. It is a dependency of the AeroGear Push module and you cannot live without it as well, but you can use a modular dependency. I’ve addressed this in an issue [4] which leads to another one [5]. It was fixed (there is Google Play Services 7.8.0 already though), but not released. Bouncycastle and Sprongycastle are related to security and are dependencies of the AeroGear Store module which is a dependency of the AeroGear Authz module. I’m not really sure I need this at all.

Let’s count again.
  • The current application: 65346 methods.
  • The application without Google Play Services and Castles: 22478.
The application can be (65346 ÷ 22478 = 2.9) times smaller.

What do you think about? Is there any chance to ditch these Castle dependencies and release the new Push version?

Regards,
Artur.


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android Dependencies and DEX Size

Daniel Passos
Hi Artur,

Very nice report

On Fri, Aug 21, 2015 at 8:16 AM, Artur Dryomov <[hidden email]> wrote:
Hi everyone,

So, I’ve just hit the famous 65 K methods count and DEX error as a sweet bonus while updating the application to latest Android 6.0-related dependencies.

Long story short, I’ve analyzed [1] dependencies [2] for the Hawkular Android Client [3]. Important notice—the application is not that big or complicated.

Methods count is below.
  • Various dependencies: 2445.
  • Java & JavaX: 1684.
  • Android Support libraries: 12988.
  • Android: 3081.
  • Google Play Services: 22022.
  • Bouncycastle: 10423.
  • Spongycastle: 10423.
  • AeroGear: 1210.
  • Application itself: 1047.
  • Total: 65346.
This is kind of disappointing. Of course I can start to blame Android Support libraries, but you clearly cannot develop apps these days without using backports and helpers. Google Play Services is a bigger deal. It is a dependency of the AeroGear Push module and you cannot live without it as well, but you can use a modular dependency. I’ve addressed this in an issue [4] which leads to another one [5]. It was fixed (there is Google Play Services 7.8.0 already though), but not released. Bouncycastle and Sprongycastle are related to security and are dependencies of the AeroGear Store module which is a dependency of the AeroGear Authz module. I’m not really sure I need this at all.

Unfortunately (or not) yes, you need this all.

TL;DR: Authz need a server token to communicate with the server, we need store this token so, authz need store lib as dependency. This token need to be stored encrypted so, store need security and castles. Makes sense?
 

Let’s count again.
  • The current application: 65346 methods.
  • The application without Google Play Services and Castles: 22478.
The application can be (65346 ÷ 22478 = 2.9) times smaller.

What do you think about? Is there any chance to ditch these Castle dependencies and release the new Push version?

About push, we don't have plan to release the play module until version 3.0.0

Anyway you can fix the problem easily using multidex[1]

[1] https://developer.android.com/tools/building/multidex.html
 

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android Dependencies and DEX Size

Artur Dryomov
Hey Daniel,

TL;DR: Authz need a server token to communicate with the server, we need store this token so, authz need store lib as dependency. This token need to be stored encrypted so, store need security and castles. Makes sense?

Totally, this can be seen at the dependency tree. Is it possible to use something more simple for such purpose? The approach of consuming almost a half of the DEX limit due to Store or (and) Security usage is kind of suspicious. Android is a limiting environment already, using a single dependency which has so many methods is strange. Include a Google Play Services dependency without modules support and you don’t even have to write an app, it will not compile already.

Not sure if it can help, but there is some sort of the repackaging project for Castles [1].

About push, we don't have plan to release the play module until version 3.0.0

Is there any recent ETA on this?

Anyway you can fix the problem easily using multidex.

I know, but it is a questionable solution which cures symptoms instead of a decease.

Artur.


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android Dependencies and DEX Size

Daniel Passos


On Fri, Aug 21, 2015 at 9:03 AM, Artur Dryomov <[hidden email]> wrote:
Hey Daniel,

TL;DR: Authz need a server token to communicate with the server, we need store this token so, authz need store lib as dependency. This token need to be stored encrypted so, store need security and castles. Makes sense?

Totally, this can be seen at the dependency tree. Is it possible to use something more simple for such purpose? The approach of consuming almost a half of the DEX limit due to Store or (and) Security usage is kind of suspicious. Android is a limiting environment already, using a single dependency which has so many methods is strange. Include a Google Play Services dependency without modules support and you don’t even have to write an app, it will not compile already.

The only think we have in mind for now is add some proguard[1] in our libs, but we are always open for new ideas.
 
Not sure if it can help, but there is some sort of the repackaging project for Castles [1].

I'll take a look at it with Bruno and do some tests.
 
About push, we don't have plan to release the play module until version 3.0.0

Is there any recent ETA on this?

Yes, schedule for October with UPS 1.2[2]
 
Anyway you can fix the problem easily using multidex.

I know, but it is a questionable solution which cures symptoms instead of a decease.

Artur.

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev