Hi
I was prompted once again by a client to investigate Android library module integration into externals. The critical one at the moment is google play services but it seems to me that it wouldn't be a bad plan to have a general mechanism for including a native library module . Particularly now we have intent support it introduces some interesting possibilities.
I can put some time in on this but it would be helpful if I can work with whoever is the main Android dev. Ian?
Cheers
Monte
android library modules
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
android library modules
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android library modules
I found this which might be helpful https://gist.github.com/antoinevg/6f9fe7f332b88d5c019e
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android library modules
@monte: I took a look (again) at the AAR stuff today... It does look a little painful :S
At this point I've currently determined that we'll have to add some sort of 'manifest' merging facility (which would be a neat thing anyone - in terms of people providing custom manifests and have them unify with options in the standalone builder). I've still to dig in deeper to understand what else we need to do.
I suspect we'll want to add some ability to ensure that the included Java and native components are 'shared' amongst any extensions using them - ideally this is something which would fit into the idea of 'extensions' in LC8 since there are similar issues there (imagine if two different extensions used the same third-party compiled library - we'd not want to include two copies of the library).
More thought and investigation is definitely needed here.
At this point I've currently determined that we'll have to add some sort of 'manifest' merging facility (which would be a neat thing anyone - in terms of people providing custom manifests and have them unify with options in the standalone builder). I've still to dig in deeper to understand what else we need to do.
I suspect we'll want to add some ability to ensure that the included Java and native components are 'shared' amongst any extensions using them - ideally this is something which would fit into the idea of 'extensions' in LC8 since there are similar issues there (imagine if two different extensions used the same third-party compiled library - we'd not want to include two copies of the library).
More thought and investigation is definitely needed here.
Re: android library modules
@LCMark I think in terms of the jars and sos (in or out of aar) there's no huge issue as they will just write over each other. I guess there's the possibility of different extensions requiring different versions... Something that works most of the time is good enough for me at this stage though.
The difficulty with aar is the manifests and resources. In the end I could be reasonably happy with a the existing custom manifest template which I contributed a while back and something that extracted the jars, sos and resources from the aar and put them in the right spot or otherwise did the right thing with them.
This looks to be what's required for to generate R.java which I presume pulls in resources from all the library packages:
And from build.xml
The difficulty with aar is the manifests and resources. In the end I could be reasonably happy with a the existing custom manifest template which I contributed a while back and something that extracted the jars, sos and resources from the aar and put them in the right spot or otherwise did the right thing with them.
This looks to be what's required for to generate R.java which I presume pulls in resources from all the library packages:
Code: Select all
aapt p[ackage] [-d][-f][-m][-u][-v][-x][-z][-M AndroidManifest.xml] \
[-0 extension [-0 extension ...]] [-g tolerance] [-j jarfile] \
[--min-sdk-version VAL] [--target-sdk-version VAL] \
[--max-sdk-version VAL] [--app-version VAL] \
[--app-version-name TEXT] [--custom-package VAL] \
[-I base-package [-I base-package ...]] \
[-A asset-source-dir] [-G class-list-file] [-P public-definitions-file] \
[-S resource-sources [-S resource-sources ...]] [-F apk-file] [-J R-file-dir] \
[raw-files-dir [raw-files-dir] ...]
Package the android resources. It will read assets and resources that are
supplied with the -M -A -S or raw-files-dir arguments. The -J -P -F and -R
options control which files are output.
Code: Select all
<echo level="info">Handling Resources...</echo>
<aapt executable="${aapt}"
command="package"
verbose="${verbose}"
manifest="${out.manifest.abs.file}"
originalManifestPackage="${project.app.package}"
androidjar="${project.target.android.jar}"
rfolder="${gen.absolute.dir}"
nonConstantId="${android.library}"
libraryResFolderPathRefid="project.library.res.folder.path"
libraryPackagesRefid="project.library.packages"
libraryRFileRefid="project.library.bin.r.file.path"
ignoreAssets="${aapt.ignore.assets}"
binFolder="${out.absolute.dir}"
proguardFile="${out.absolute.dir}/proguard.txt">
<res path="${out.res.absolute.dir}" />
<res path="${resource.absolute.dir}" />
</aapt>
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
android library modules
Thanks for the useful information about the OpenGL3 <-> GLES2 similarity. Ive already used glm in a simple project for android using GLES2, so is should not be a problem.