Android build and hardware support

[AbandonedCart]

See commit titles for details

[AbandonedCart]

A quick note: You will most likely need to open the android_build/local.properties and add ndk.dir=/path/to/android-ndk unless you have an ANDROID_NDK environment variable defined

[jpd002]

Humm, is there some kind of naming convention for the NDK's root path environment variable? I've been using ANDROID_NDK_ROOT, but is ANDROID_NDK preferable?

[AbandonedCart]

ANDROID_NDK is the one typically used by ant. Eclipse (and possibly the ADT rip-off Android released later) use NDK_ROOT internally.

In the build.xml you would change

<condition property="ndk.dir" value="${env.ANDROID_NDK}">
    <isset property="env.ANDROID_NDK" />
</condition>

to

<condition property="ndk.dir" value="${env.ANDROID_NDK_ROOT}">
    <isset property="env.ANDROID_NDK_ROOT" />
</condition>

if you wanted to use ANDROID_NDK_ROOT instead

[jpd002]

Thanks for the changes. I've done some tests on my side and I've got some questions/comments:

• I like the idea of building the native code from Ant and I think that's what makes more sense, but it seems impossible to generate a debug native build (with NDK_DEBUG=1) with those changes at the moment. Cleaning is also a problem because ndk-build has to be called twice (once with NDK_DEBUG=0 and then with NDK_DEBUG=1) for proper cleanup.
• I also like the idea of finding all disk images and ELF files accessible to the device automatically. This might still be WIP on your side or maybe it's me being dense, but I'm not quite sure I understand why there's still a concept of "CurrentDirectory" (with the possibility of clearing it) when there's no actual filesystem navigation anymore.

What I'll do for now is cherry-pick the changes related to Android TV and application exit so they can be in tomorrow's weekly build.

[AbandonedCart]

You would build the debug version using ant debug, same as cleaning before a build would be ant clean debug and ant clean release.

The process does not create a stored list of files, it finds the files. The more you search, the more time it takes. By storing the enclosing directory the first time a file is selected, that is the "root" next time. You may move folders, so there is an option to clear it.

I'll avoid submitting anything together in the future. I get wanting bits and pieces, but it will be easier to let me reorganize the pull instead. (See below)

[jpd002]

Well, I'll try the debug/release build again, but using "ant debug" or "ant release" didn't seem to make any difference for native code.

And sorry about the cherry picking, I will ask before doing something like that again.

[Zer0xFF]

@LoungeKatt you could have created a new branch for the pull request, to avoid the undo and rebase.

[AbandonedCart]

@Thunder07 I did, but it was my upstream tracking branch. I have it all automated to pull in new changes.

@jpd002 I probably should have explained that. I meant if you have a part you want, I can restructure the pull so you don't need to pick. There is nothing to be sorry about, I was the one that put a bunch of unrelated stuff in the same pull. It was my mess to clean up.

[AbandonedCart]

You don't need the NDK environment variable at all, so if you use something else it can be left as is. Instead, you can open the local.properties file and add ndk.dir=/path/to/ndk-folder and it will survive an "android update project" (but you have to add it to each project that uses the ant ndk builder).

For debug / release you would also add ndkbuildopt="NDK_DEBUG=1" or ndkbuildopt="NDK_DEBUG=0" (I could have sworn it was set automatically, but I have always built with release and never needed to verify)

[jpd002]

@LoungeKatt Would it make sense to have the Ant build rules (in custom_rules.xml) add the proper NDK_DEBUG option automatically whether we are doing a debug or release build? Would it also make sense to make the "clean" target call ndk-build twice (once for debug and once for release) to make sure everything is cleaned?

[AbandonedCart]

It's possible to add separate debug and release builds to the NDK build. It should even be possible to add the automation I thought it already had. It would just be a matter of having the ant debug and release commands pass the ndkbuildopt instead of adding them.

If there is something in one that isn't in the other, you wouldn't be building it for an unclean module to matter and it would get cleaned when you are. I imagine it is possible to run clean twice, but I don't understand the reason.

[Zer0xFF]

@LoungeKatt I think he's asking if calling clean once would clean both the debug and release builds.

[AbandonedCart]

@Thunder07 make the "clean" target call ndk-build twice

Either way, if https://developer.android.com/ndk/guides/ndk-build.html#dvr isn't leaving out anything, then ndk-build clean cleans everything regardless what NDK_DEBUG value is set.

[jpd002]

@LoungeKatt Well, we would expect the NDK's clean target to clean everything, but it doesn't for some reason. Calling the clean target with NDK_DEBUG=0 or no NDK_DEBUG set, cleans the obj/local/$(arch)/objs folder while calling it with NDK_DEBUG=1 cleans obj/local/$(arch)/objs-debug, hence why we need to call it twice to clean everything.

I don't know, maybe my setup is weird and that people don't usually build debug libraries. Anyways I think I'm ready to merge the build system changes, but I still need some time to study the changes to the file locator and the OpenGL ES 2.0 change. Would it be possible to move the build system commits to another PR? Thanks!

[AbandonedCart]

I see what you mean. Technically, it would clean obj if you did another release, or obj-debug if you did another debug, but it would ignore the other. You would always get a clean build, just not necessarily always start with everything clean (if that makes sense).

[AbandonedCart]

File location: https://github.com/AbandonedCart/Play-/commit/bca0437444b7e3bb216d6b53477f371a874852b5

Important note: this is only the backend. In theory, you would connect this to something like GamesDB and then check for matches. Only the files with matches would make the "select an item to select a folder" list. Once you set the folder, it would then be able to fill in a list of games in the folder whether they had GamesDB entries or not. There is a good chance not every game will have an entry, but an equal or higher chance at least one game will have an entry. You might call it the shotgun approach.

GLES 2 Manifest: https://github.com/AbandonedCart/Play-/commit/a5eeb57e4e5725befaf40ef3736382f662cbbc04

The commits are still accessible on my test branch, but the pull is now NDK only

[LinkofHyrule89]

Might want to consider also giving the ability to set custom box art so that those without box art or people that just want to customize can do that.

[AbandonedCart]

@LinkofHyrule89 that would be part of the UI portion. This only goes as far as picking what files should be considered games.

[LinkofHyrule89]

Yeah I understand that this would be in the distant future. Just having a system where we can basically not have to deal with the file picker would be awesome though.

[jpd002]

Thanks for the changes. I've made some adjustments to the build scripts to make them work as they were before.