|
|
|
This thread is locked; no one can reply to it.
|
| Android Release Build |
|
Todd Cope
Member #998
November 2000
 |
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
Member #11,410
October 2009
|
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. Agui GUI API -> https://github.com/jmasterx/Agui |
|
Todd Cope
Member #998
November 2000
|
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
Member #476
June 2000
 |
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
Member #998
November 2000
|
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
Member #476
June 2000
|
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
Member #998
November 2000
|
Thanks for the tip. I'll try that and see if I can track down where it is freezing. |
|
Elias
Member #358
May 2000
|
Enable the WANT RELEASE LOGGING option in cmake and the logs are generated also in release builds. -- |
|
Todd Cope
Member #998
November 2000
|
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: 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
Second in Command
February 2005
 |
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. They all watch too much MSNBC... they get ideas. |
|
|
