Hi there
I was wondering if its possible for the enduser to merge the APK files of the main build and the plugins.
When you have installed every plugin like me, its a real pain to browse through your apps list, especially if your phone has the habit to throw the dice on the sort order.
I presume you (as in the developers) would not want to release everything in a single apk to keep the installed packages smaller, hence my question if its possible for US.
Merging main and plugin APKs
Moderator: ScummVM Team
Merging main and plugin APKs
Last edited by Timiditas on Tue Mar 04, 2014 2:11 pm, edited 1 time in total.
Well, it would make installing daily builds easier for developers and power users (providing their phones have sufficient storage space) if ScummVM comes as a single APK to install, upgrade and remove.
As for releases, it probably should be an option so we can look at that once the buildbot has this working for development purposes.
As for releases, it probably should be an option so we can look at that once the buildbot has this working for development purposes.
If you're able to compile for yourself, this is easy to do. Just omit the --enable-plugins --default-dynamic flags, and you'll build a single *.apk.
Otherwise, as the buildbot already provides three different daily Android builds (ARM, MIPS and x86), perhaps another configuration where all the engines are enabled could be added.
Otherwise, as the buildbot already provides three different daily Android builds (ARM, MIPS and x86), perhaps another configuration where all the engines are enabled could be added.
@Nitrus: Errm... Noo...
I may be wrong here, but based on my reading of scummvm/backends/platform/android/android.mk rules, the only supported APK output is 1 for the main executable (APK_MAIN) and 1 for each engine (APK_PLUGINS). Timiditas is talking about having the main executable and all the plugins in a single APK for ease of installation.
And I am looking at sorting out the MIPS and x86 Android builds on the buildbot, but currently they are not working so not yet!
Will sort both these issues given some time... maybe later today.
I may be wrong here, but based on my reading of scummvm/backends/platform/android/android.mk rules, the only supported APK output is 1 for the main executable (APK_MAIN) and 1 for each engine (APK_PLUGINS). Timiditas is talking about having the main executable and all the plugins in a single APK for ease of installation.
And I am looking at sorting out the MIPS and x86 Android builds on the buildbot, but currently they are not working so not yet!
Will sort both these issues given some time... maybe later today.
I may be misunderstanding something here, possibly the intention and goal.
What I'm trying to say is, just yesterday I compiled a single *.apk, copied it to my phone and installed it from there. With it, I got all of the officially supported engines. I didn't download nor install any other (plugin) *.apks.
(I could have gotten the unsupported engines too, if I had enabled them from ./configure)
I compiled it with the prebuilt libs, with:
./configure --host=android --with-tremor-prefix=/opt/android/3rd-android-4-armeabi-release --with-mad-prefix=/opt/android/3rd-android-4-armeabi-release --with-flac-prefix=/opt/android/3rd-android-4-armeabi-release --enable-release --enable-optimizations
(I don't think optimizations are needed with release, but I put it in just to be on the safe side).
The resulting *.apk was around 9.75MB
Also, the newer SDK (and possibly NDK) won't work with the current setup, I think I was using the newest, which failed because some of the tools are moved in a different place, and some (E.G. sdk/tools/apkbuilder, which is required in the last steps) are just gone. So either reverting to the older one, or replacing the tools to their required locations will work.
And I had to correct the libs' paths from the compile tutorial just a bit, to add the -release part (e.g. 3rd-android-4-armeabi-release).
Again, I might be misunderstanding the end goal here.
EDIT: Here's a pastebin of the build's file/folder structure, after compiling. Not sure if it'll help though.
What I'm trying to say is, just yesterday I compiled a single *.apk, copied it to my phone and installed it from there. With it, I got all of the officially supported engines. I didn't download nor install any other (plugin) *.apks.
(I could have gotten the unsupported engines too, if I had enabled them from ./configure)
I compiled it with the prebuilt libs, with:
./configure --host=android --with-tremor-prefix=/opt/android/3rd-android-4-armeabi-release --with-mad-prefix=/opt/android/3rd-android-4-armeabi-release --with-flac-prefix=/opt/android/3rd-android-4-armeabi-release --enable-release --enable-optimizations
(I don't think optimizations are needed with release, but I put it in just to be on the safe side).
The resulting *.apk was around 9.75MB
Also, the newer SDK (and possibly NDK) won't work with the current setup, I think I was using the newest, which failed because some of the tools are moved in a different place, and some (E.G. sdk/tools/apkbuilder, which is required in the last steps) are just gone. So either reverting to the older one, or replacing the tools to their required locations will work.
And I had to correct the libs' paths from the compile tutorial just a bit, to add the -release part (e.g. 3rd-android-4-armeabi-release).
Again, I might be misunderstanding the end goal here.
EDIT: Here's a pastebin of the build's file/folder structure, after compiling. Not sure if it'll help though.
@Nitrus: AH! I think that will result in a "monolithic" build i.e. one big executable with all engines compiled in inside the single APK... which is fine if your phone has sufficient memory to load all the engines at once.
We can provide that fairly easily as you indicate, but I meant producing a dynamic plugins enabled build i.e. with a small executable loading a single engine at a time from a selection of plugins at runtime (thus much less RAM usage), but instead of having separate APKs... the main executable and the engine plugins are all in a single APK for ease of installation.
We can provide that fairly easily as you indicate, but I meant producing a dynamic plugins enabled build i.e. with a small executable loading a single engine at a time from a selection of plugins at runtime (thus much less RAM usage), but instead of having separate APKs... the main executable and the engine plugins are all in a single APK for ease of installation.
{...}what exactly might result in a crash on Android 2.3 phones with little memory whose support just has been fixed.digitall wrote:@Nitrus: AH! I think that will result in a "monolithic" build i.e. one big executable with all engines compiled in inside the single APK... which is fine if your phone has sufficient memory
@digital: Ahhh I see what you mean. Yeah, I guessed I had the end goal wrong. In that case, I have absolutely no idea how that can be achieved, but wouldn't that be a good thing for everybody? I mean, saving RAM is good in any situation
@Timiditas: I was rocking ScummVM on a Samsung Galaxy Mini I (GT-S5570) just until a month ago, and you're right, I remember having to install the plugins separately. This would be an excellent addition if it's possible to do.
@Timiditas: I was rocking ScummVM on a Samsung Galaxy Mini I (GT-S5570) just until a month ago, and you're right, I remember having to install the plugins separately. This would be an excellent addition if it's possible to do.
It is rather awesome.. only problem the play store version being broken on 5.x Lollipop, any chance of a 1.8.0 based build that works (like the current nightlies), making it to the play store anytime soon so we don't have to install all the engines?sndwv wrote:I was happy to find the engine plugins consolidated into the main apk for 1.7. Will this now also happen with the nightly builds (for ease of installation)?