Android documentation/project-template refresher

edited August 2014 in General discussions
It's taken a week to battle my way to getting a larger project compiled and running on an Android device.

The main help for getting android apk's compiled is still in the minimal help doc in the wiki: http://orx-project.org/wiki/en/orx/tutorials/setup_android

However that's only half the story.

Having a suitable blank android build project is required for people to use to adapt around their own projects.

Creating a new project from within eclipse is *not* suitable due to the orx dependency. It is only useful for compiling the apk file.

The question is... should the orx/code/demo/android project be considered as the minimum template for an android project?

It does give a newbie the best chance for success.

The problem is, it misses a few things for wrapping a more complex game, like a missing STL reference for c++ projects.

So should the demo be seen as the default template for android... or should another project be defined and shipped with orx that contains the STL references, and some more generic naming for the project and manifest?

Would very much like to discuss the way forward.

Comments

  • edited August 2014
    I haven't walked down the Android path (yet), so I can't really give any good opinion on this topic.
    However, I think any STL reference is more of a user choice.
    Personally I don't want to have it referenced even though all my game projects are coded in C++.
  • edited August 2014
    True. I guess from one viewpoint, as a project becomes significant, the chances that the developer is going to use something like <vector> is pretty likely. Therefore STL would be required, and become another hurdle that the android-green developer has to go off and google.

    But... this could be covered as part of the "upcoming" android documentation.
  • edited August 2014
    I think the STL is really more about general C++ practices, though I don't know about Android specifics with respect to that.

    In my experience, STL use behavior is quite the opposite of what you describe. I've worked for 5 different game companies over a 13 years span, and the only common thing they had, code-wise, was they all proscribed the use of STL (as well as exceptions, RTTI, etc). =)

    Some companies even attempted to correct the default implementations, like the EASTL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
    Most of them would use custom containers, which API is sometimes loosely based on STL.

    That being said, my background is console/PC game development, I don't know if the practices are similar with mobile dev (though native Java/Obj-C environments probably brought different constraints).
  • edited August 2014
    I'd have to agree, I'm not experienced enough to say.

    But when working through getting my project compiling, it complained about <vector> specifically. After searching around I found the answer was that I was missing the reference:

    APP_STL := stlport_static

    from my Application.mk.

    I suppose that's really what I'm getting at.
  • edited August 2014
    /code/demo/android is really a demo, the most simple app to test orx is running.

    it can be used as a template for your games but the simplicity of the demo only depends on orx.

    it's up to you to configure your android build for your needs.
    If you need help I can help you with this.
  • edited August 2014
    Yep I've managed to get a reasonably complicated project working on a device using the demo as a template (with alterations). I'm working on documentation for this and would very much appreciate you casting your eye over it.
  • edited August 2014
    sausage wrote:
    But when working through getting my project compiling, it complained about <vector> specifically. After searching around I found the answer was that I was missing the reference:

    APP_STL := stlport_static

    from my Application.mk.

    Yep, that info definitely would be helpful to have on the wiki, even though it's in the NDK documentation, it's easy to miss.

    I should be starting my first android setup next week and I'll be using your updated tutorials as well. :)
  • edited August 2014
    I should have the documentation ready by then but I might have roll back the orx head a few months to finish the docs, as the new android build just isn't working out for me.

    Earlier versions of the android build were sweet, but the most recent is causing me grief. Working with lydesik to hopefully resolve.
  • edited August 2014
    Oh? Do you have any details as I might run into the same issues?
  • edited August 2014
    At this stage, best to just compile orx itself, the demo, and try to install to an API 9, API 14, and API 19 machine.

    You'll get an apk, but the demo will close without error running on a device.

    I had success with earlier versions.
  • edited August 2014
    Here is the result of compiling the very latest orxLib and demo, and running the orxDemo.apk against as many things as I could practically get my hands on:

    * Real 2.3 Device - Passed
    * Real 4.04 Device - Failed, Quits immediately.
    * VirtualBox Android 2.3 - Failed with error (expected I guess)
    * VirtualBox Android 4.3 - Failed with error
    * Bluestacks on Windows (based on 2.3) - Passed

    Interesting to note that VirtualBox instances can't run orxDemo.apk but Bluestacks can. A real 2.3 can. Nothing else I try will.

    Attached is the log from the 4.0.4 device.

    Lydesik, I'd appreciate your thoughts on the result and I can supply the actual orxDemo.apk if you like. https://forum.orx-project.org/uploads/legacy/fbfiles/files/motorola_zoom_404_running_demo.txt
  • edited August 2014
    If i read correctly this log, it crashes inside openal's init, probably with some ugly stack overflow as somehow the instruction pointer (pc) ends up pointing at what looks like data and not code, judging from the address ranges.

    If you were to try without sound (by using the dummy sound plugin, for example), you should be able to go further before lydesik gets a chance to look at it.

    You could also try to compile openal-soft in debug as it might provide more useful log, or at least tell us in which call precisely things go haywire.

    Good luck! :-)
  • edited August 2014
    That's an excellent idea. I'll give it a shot and report back.
  • edited August 2014
    Hi sausage,

    the error in the log is ILL_ILLOPC for illegal opcode which is very weird...

    here is a build I just created by recompiling orx with android ndk-r10

    I'll test it tomorrow on a Tegra2 device (like the Motorola XOOM).

    Can you check this apk on your device. https://forum.orx-project.org/uploads/legacy/fbfiles/files/app_debug.zip
  • edited August 2014
    Hi Lydesik,

    Great to see you back. The app_debug.apk failed as well. I've sent you the log via email.
Sign In or Register to comment.