# Android SDK shortfall in fully native use **URL:** \ **Category:** PowerVR Insider\ **Created:** [August 8, 2012, 3:29pm UTC](https://forums.imgtec.com/t/android-sdk-shortfall-in-fully-native-use/1492 "2012-08-08T15:29:49Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![jheanley](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/jheanley/32/121_2.png) [@jheanley](https://forums.imgtec.com/u/jheanley)\ **Post date:** [August 8, 2012, 3:29pm UTC](https://forums.imgtec.com/t/android-sdk-shortfall-in-fully-native-use/1492/1 "2012-08-08T15:29:49Z")
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. ---
**Author:** ![Scott](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/scott/32/256_2.png) [@Scott](https://forums.imgtec.com/u/Scott)\ **Post date:** [August 9, 2012, 3:36pm UTC](https://forums.imgtec.com/t/android-sdk-shortfall-in-fully-native-use/1492/2 "2012-08-09T15:36:18Z")
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 ---
**Author:** ![jheanley](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/jheanley/32/121_2.png) [@jheanley](https://forums.imgtec.com/u/jheanley)\ **Post date:** [August 10, 2012, 7:23pm UTC](https://forums.imgtec.com/t/android-sdk-shortfall-in-fully-native-use/1492/3 "2012-08-10T19:23:04Z")
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. ---
**Author:** ![franck-2](https://avatars.discourse-cdn.com/v4/letter/f/57b2e6/32.png) [@franck-2](https://forums.imgtec.com/u/franck-2)\ **Post date:** [September 14, 2012, 6:05pm UTC](https://forums.imgtec.com/t/android-sdk-shortfall-in-fully-native-use/1492/4 "2012-09-14T18:05:59Z")
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