Android SDK shortfall in fully native use

This topic contains 3 replies, has 3 voices, and was last updated by  franck 5 years, 1 month ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #30939

    jheanley
    Member

    Hi, after downloading the latest android sdk i noticed there was no more support for a java wrapped version of pvrshell. Whilst fully native activities may simplify certain aspects you lose a lot of functionality available only from Java based activities. Removing a java wrapped pvrshell is severely limiting the potential of android based apps/games.

    Things lost:
    -soft keyboard (although i noticed pvrshell does not use any character key input)
    -No implementation in latest pvr for saving files on android, only reading them
    -adware
    -in-app billing
    These are just a few things i could think of on the spot, there will be a lot more. If there is a reliable way of getting a location to save files to using native activities in android please let me know, keeping in mind sdcard is not reliable enough (not all people have them). As for adware, this is becoming a very desirable method for people to use to help increase revenue, preventing access to it is not ideal.
    #36053

    Scott
    Moderator

    Hi,

    I’m not familiar with the requirements for adware and in-app
    billing but I assume it would be possible to “add” back the things lost by
    using a combination of JNI and changing the application to use a java class
    that extends NativeActivity instead of android.app.NativeActivity.

    Thanks,

    Scott

    #36054

    jheanley
    Member

    Hi Scott,

    Yes, I have since added back in the use of jni by merging the latest SDK with a previous one. I would only suggest that perhaps future sdk releases could include the ability to use either a java wrapper or a fully native activity, especially considering backwards compatibility with previous versions of android. Many of the API’s added for native activities are not available in devices shipped with previous versions of android. I realise that this SDK is designed to be at the forefront of graphics technology, but some backwards compatibility should be considered.
    Saying that, the majority of the SDK API’s released here have been a huge benefit to my project and I am very grateful for the work done by Imagination Tech. This has massively simplified the process of building for android while keeping a win32 version for debugging (i hate debugging NDK code on the device).
    Cheers,
    Jules.
    p.s. The order of message processing and graphics flushing in win32 sdk causes issues with trying to get WM_CHAR events. It appears eglSwapBuffers allows windows messages to be dispatched without being translated. For now I have swapped the order of OsRenderComplete and ApiRenderComplete to ensure WM_CHAR events are translated from keydown events and dispatched properly. On android this should be less problematic as these will come from soft keyboard feedback.
    #36055

    franck
    Member

    Hello and sorry to unding this post a little but I met the same issue. I’m building an AR app that uses the vuforia SDK, the app is almost ready but I wish I could optimize it a little by using the POD format (no heavy headers) and binary shaders. Everything will have to remain the same as I need JAVA for both UI and the AR OpenGL (context, config, renderer, etc…) which means : java wrapper and no use of PVRShell. Is it possible ? Have you any clue what a makefile should look like ?

    Thanks

    franck2012-09-14 20:13:15

Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic.