Android Release Build
Todd Cope

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.

jmasterx

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.

Todd Cope

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.

Thomas Fjellstrom
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.

Todd Cope

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.

Thomas Fjellstrom

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.

Todd Cope

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

Elias

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

Todd Cope

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.

Arthur Kalliokoski
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.

Thread #613497. Printed from Allegro.cc