Android Release Build

no-reply@allegro.cc (Todd Cope) — Fri, 15 Nov 2013 04:14:47 +0000

I am getting ready to release the Android version of my game and I noticed the game freezes on startup when I use the release build of Allegro. Is it possible to use the release build or should I just stick with the debug build?

I was able to make a release build of my game using the debug libraries, but I would like to have everything optimized for the release. Has anyone successfully used the release build? I feel like there just might be a bug in my code that doesn't manifest itself when using the debug version.

no-reply@allegro.cc (jmasterx) — Sat, 16 Nov 2013 23:33:43 +0000

Keep in mind that usually the debug version initializes variables to 0. You might have an uninitialized variable or perhaps uninitialized pointer.

Is there a way you could see the area it crashes? Do you have a way to produce a Release With Debug Info build?

If not, perhaps print a log in major areas and see around where it stops logging and check that area.

no-reply@allegro.cc (Todd Cope) — Sun, 17 Nov 2013 08:49:36 +0000

I was going to do the usual debug logging, it's just much more cumbersome on Android.

The readme says to use the debug version. I was mainly just wondering if anyone uses the release build and can verify that it works. My game works fine in Windows, OS X, and Linux in release mode.

no-reply@allegro.cc (Thomas Fjellstrom) — Sun, 17 Nov 2013 08:51:49 +0000

Todd Cope said:

I was going to do the usual debug logging, it's just much more cumbersome on Android.

It's "unsupported" but I tend to use allegro's ALLEGRO_DEBUG macro for loging on android. its really an internal, but it works fine if you want to log to the adb console.

no-reply@allegro.cc (Todd Cope) — Sun, 17 Nov 2013 10:52:50 +0000

Yeah, that's what I do already. Can I use that macro in release mode? I was under the impression it gets defined away in release mode. I don't remember seeing any of the debug messages from the native code when I tested the release build.

no-reply@allegro.cc (Thomas Fjellstrom) — Sun, 17 Nov 2013 10:56:21 +0000

Hm, yeah, it's compiled out in release mode. you could make your own macro that calls __android_log_write.

eg: __android_log_write(ANDROID_LOG_ERROR, "Tag", "Error here");

May need to link to the log library.

no-reply@allegro.cc (Todd Cope) — Sun, 17 Nov 2013 11:11:41 +0000

Thanks for the tip. I'll try that and see if I can track down where it is freezing.

no-reply@allegro.cc (Elias) — Sun, 17 Nov 2013 18:40:51 +0000

Enable the WANT RELEASE LOGGING option in cmake and the logs are generated also in release builds.

no-reply@allegro.cc (Todd Cope) — Fri, 22 Nov 2013 02:18:37 +0000

Thanks! I logged my program's initialization phase and it freezes when trying to load TTF fonts. I'll look into it further when I have more time and post the results here.

Append: It seems I am running into the error described in this thread. I'm going to try some workarounds...

Append 2: I was able to get TTF files to load by telling ant not to compress TTF files. Here's the excerpt from my new build.xml:

#SelectExpand
  1<target name="-package-resources" depends="-crunch">  2<!-- only package resources if*not* a library project -->  3<do-only-if-not-library elseText="Library project: do not package resources...">  4<aapt executable="${aapt}"  5                    command="package"  6                    versioncode="${version.code}"  7                    versionname="${version.name}"  8                    debug="${build.is.packaging.debug}"  9                    manifest="${out.manifest.abs.file}" 10                    assets="${asset.absolute.dir}" 11                    androidjar="${project.target.android.jar}" 12                    apkfolder="${out.absolute.dir}" 13                    nocrunch="${build.packaging.nocrunch}" 14                    resourcefilename="${resource.package.file.name}" 15                    resourcefilter="${aapt.resource.filter}" 16                    libraryResFolderPathRefid="project.library.res.folder.path" 17                    libraryPackagesRefid="project.library.packages" 18                    libraryRFileRefid="project.library.bin.r.file.path" 19                    previousBuildType="${build.last.target}" 20                    buildType="${build.target}" 21                    ignoreAssets="${aapt.ignore.assets}"> 22<res path="${out.res.absolute.dir}"/> 23<res path="${resource.absolute.dir}"/> 24                <nocompress extension="ttf" />
 25<!--<nocompress /> forces no compression on any files in assets or res/raw --> 26<!--<nocompress extension="xml"/> forces no compression on specific file extensions in assets and res/raw --> 27</aapt>
 28</do-only-if-not-library>
 29</target>

Append 3: It appears al_fsize() doesn't work on compressed files within the APK. I also found out that the release build is failing to use the PhysFS add-on for resource loading. In my framework, I have it attempt to locate the app's resources via PhysFS. If that fails, it sets the APK interface.

So ultimately, the issues I am having are due to the PhysFS code path failing and falling back to the APK interface.

Append 4: I fixed the problem by passing the path returned by al_get_standard_path(ALLEGRO_EXENAME_PATH) to PHYSFS_init() instead of argv[0] from main(). I don't see why it would be different between debug and release builds but apparently it is.

no-reply@allegro.cc (Arthur Kalliokoski) — Fri, 22 Nov 2013 04:15:22 +0000

Todd Cope said:

I don't see why it would be different between debug and release builds but apparently it is.

Heh, I remember getting upset about Turbo Debugger tidying up the command line args in the DOS Program Segment Prefix when I was trying to get a program to break while testing.