[jitsi-dev] some questions about updating jitsi-android to latest libs


#1

Hi,

I have updated the android port of jitsi to the latest libs, that is,
running 'copy-jitsi-bundle' ant target and fixing discrepancies (had
to disable h264 video support though). The code now compiles but the
total number of methods has reached the 65536 limit of dalvik.

I see there's already a class loader for dynamic loading of dex code,
LibDexLoader, but it's not clear to me how the jitsi-bundle-dex.jar
get created in build.xml. How do I tell build.xml to include some
other bundles in that file?


#2

Hi,

···

On Thu, Jun 19, 2014 at 11:17 PM, pierigno <pierigno@gmail.com> wrote:

Hi,

I have updated the android port of jitsi to the latest libs, that is,
running 'copy-jitsi-bundle' ant target and fixing discrepancies (had
to disable h264 video support though). The code now compiles but the
total number of methods has reached the 65536 limit of dalvik.

I see there's already a class loader for dynamic loading of dex code,
LibDexLoader, but it's not clear to me how the jitsi-bundle-dex.jar
get created in build.xml. How do I tell build.xml to include some
other bundles in that file?

lib/asset-bundles folder contains those .jar files that will be
compiled to assets/jitsi-bundles.dex. The actual dexing process of
those libs is defined in "create-asset-dex" ant target. It might be
not trivial task to move more .jar files to assets though.

Regards,
Pawel


#3

Main limitation when moving jitsi bundles to asset .dex file is the
fact that only those jars that are not directly referenced from
Android code can be put there. Otherwise there is problem during
compilation as far as I can remember. And not directly referenced are
those classes that are loaded by OSGi and are standalone service
providers. Let's say we have "serviceA" interface and "serviceAImpl"
class that implements it. Each of those is defined in separate .jar
file. If we use only serviceA interface in Android code then
serviceAImpl jar can go to asset .dex file.


#4

thanks Pawel, I see the problem.

Luckly google has provided a new --multi-dex option for dx tool, some
project like ruboto already make use of it: here's a snippet of code
of their makefile
https://github.com/ruboto/ruboto/blob/master/assets/rakelib/ruboto.rake
(search for macrodef multi-dex-helper).

I've imported their multi-dex-helper and dex-helper ant tasks and
created a LibDexLoader2.java class to deal with the third classes.dex
file created by them (in addition to jitsi-bundles.dex). I'm now able
to compile and run it on my device, am also able to register an xmpp
account and see incoming chat messaging in notification area, but as
soon as I try to start a chat activity jitsi crashes because of some
NoClassDefFoundError exception. I think I need to get rid of
create-asset-dex ant task and integrate it into the multi-dex-helper
somehow.

multi-dex.xml (9.96 KB)

LibDexLoader2.java (3.15 KB)

···

2014-06-20 8:04 GMT+02:00 Paweł Domas <pawel.domas@jitsi.org>:

Main limitation when moving jitsi bundles to asset .dex file is the
fact that only those jars that are not directly referenced from
Android code can be put there. Otherwise there is problem during
compilation as far as I can remember. And not directly referenced are
those classes that are loaded by OSGi and are standalone service
providers. Let's say we have "serviceA" interface and "serviceAImpl"
class that implements it. Each of those is defined in separate .jar
file. If we use only serviceA interface in Android code then
serviceAImpl jar can go to asset .dex file.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi,

···

On Mon, Jun 23, 2014 at 6:41 PM, pierigno <pierigno@gmail.com> wrote:

thanks Pawel, I see the problem.

Luckly google has provided a new --multi-dex option for dx tool, some
project like ruboto already make use of it: here's a snippet of code
of their makefile
https://github.com/ruboto/ruboto/blob/master/assets/rakelib/ruboto.rake
(search for macrodef multi-dex-helper).

I've imported their multi-dex-helper and dex-helper ant tasks and
created a LibDexLoader2.java class to deal with the third classes.dex
file created by them (in addition to jitsi-bundles.dex). I'm now able
to compile and run it on my device, am also able to register an xmpp
account and see incoming chat messaging in notification area, but as
soon as I try to start a chat activity jitsi crashes because of some
NoClassDefFoundError exception. I think I need to get rid of
create-asset-dex ant task and integrate it into the multi-dex-helper
somehow.

Thank you for your efforts ! We will have a look and try to integrate.
It might take from few days to a week.

Regards,
Pawel


#6

Ok, I think I got rid of create-asset-dex ant task by putting jarjars
modifications inside setup-libs and using the ruboto tasks: now all
the bundles are treated as equals, and dx --multi-dex will create a
second classes2.dex a soon as it detects more room is needed for
methods.

The cool thing is that dx accept an --main-dex-list parameter through
which I can tell him exactly which classes should be put inside the
main classes.dex and which ones can be put on an external
classes2.dex. The classes2.dex is then packaged as jar inside the
apk's assets directory, so LibDexLoader2.java is not needed anymore.

As of now just a modified build.xml is needed, together with a
classlist.txt, in order to rebuild the current 4 month old
jitsi-android. I've just tested xmpp here and it works rather well, it
receives messages and answer audio/video calls, but seems unable to
place calls. Some other source changes are instead needed to use the
current jitsi codebase. Will make a pull request from my jitsi-android
fork on github tonight or sometime this weekend.

Regards,
Pierangelo

···

2014-06-24 8:32 GMT+02:00 Paweł Domas <pawel.domas@jitsi.org>:

Hi,

On Mon, Jun 23, 2014 at 6:41 PM, pierigno <pierigno@gmail.com> wrote:

thanks Pawel, I see the problem.

Luckly google has provided a new --multi-dex option for dx tool, some
project like ruboto already make use of it: here's a snippet of code
of their makefile
https://github.com/ruboto/ruboto/blob/master/assets/rakelib/ruboto.rake
(search for macrodef multi-dex-helper).

I've imported their multi-dex-helper and dex-helper ant tasks and
created a LibDexLoader2.java class to deal with the third classes.dex
file created by them (in addition to jitsi-bundles.dex). I'm now able
to compile and run it on my device, am also able to register an xmpp
account and see incoming chat messaging in notification area, but as
soon as I try to start a chat activity jitsi crashes because of some
NoClassDefFoundError exception. I think I need to get rid of
create-asset-dex ant task and integrate it into the multi-dex-helper
somehow.

Thank you for your efforts ! We will have a look and try to integrate.
It might take from few days to a week.

Regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Patches are available at https://github.com/pierigno/jitsi-android/
under multi-dex branch

They allow to compile jitsi-android using standard multi-dex feature
of android sdk. That means that you can import latest libs and bundles
from jitsi without worrying about the 64k method limit.

Note that I've created a little bash script (generate-classlists.sh)
to generate, for each bundle, a txt file that lists all classes in
that bundle. You control which bundle gets included in classes.dex and
in which order by specifing the name of the txt file related to that
bundle in the control file classlist-order.txt. It's just a
quick-dirty hack, it's a job better suited for ant itself, bt it works
nicely for now.

the standard development procedure would then be:

ant setup-libs
./generate-classlists.sh
<edit classlist-order.txt>
ant rebuild
ant adb-install-and-run

···

2014-06-26 19:43 GMT+02:00 pierigno <pierigno@gmail.com>:

Ok, I think I got rid of create-asset-dex ant task by putting jarjars
modifications inside setup-libs and using the ruboto tasks: now all
the bundles are treated as equals, and dx --multi-dex will create a
second classes2.dex a soon as it detects more room is needed for
methods.

The cool thing is that dx accept an --main-dex-list parameter through
which I can tell him exactly which classes should be put inside the
main classes.dex and which ones can be put on an external
classes2.dex. The classes2.dex is then packaged as jar inside the
apk's assets directory, so LibDexLoader2.java is not needed anymore.

As of now just a modified build.xml is needed, together with a
classlist.txt, in order to rebuild the current 4 month old
jitsi-android. I've just tested xmpp here and it works rather well, it
receives messages and answer audio/video calls, but seems unable to
place calls. Some other source changes are instead needed to use the
current jitsi codebase. Will make a pull request from my jitsi-android
fork on github tonight or sometime this weekend.

Regards,
Pierangelo

2014-06-24 8:32 GMT+02:00 Paweł Domas <pawel.domas@jitsi.org>:

Hi,

On Mon, Jun 23, 2014 at 6:41 PM, pierigno <pierigno@gmail.com> wrote:

thanks Pawel, I see the problem.

Luckly google has provided a new --multi-dex option for dx tool, some
project like ruboto already make use of it: here's a snippet of code
of their makefile
https://github.com/ruboto/ruboto/blob/master/assets/rakelib/ruboto.rake
(search for macrodef multi-dex-helper).

I've imported their multi-dex-helper and dex-helper ant tasks and
created a LibDexLoader2.java class to deal with the third classes.dex
file created by them (in addition to jitsi-bundles.dex). I'm now able
to compile and run it on my device, am also able to register an xmpp
account and see incoming chat messaging in notification area, but as
soon as I try to start a chat activity jitsi crashes because of some
NoClassDefFoundError exception. I think I need to get rid of
create-asset-dex ant task and integrate it into the multi-dex-helper
somehow.

Thank you for your efforts ! We will have a look and try to integrate.
It might take from few days to a week.

Regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev