Query related to the final "NDK Standalone Tool Chain" release candidate

[Raman Chalotra]

Hi All,

I have been trying to port few libraries from Linux to Android. The source code is in C and build procedure is GNU style Makefiles. So, I need to use the NDK. The user of my library will be writing application in JAVA (as is obvious on Android).

I have few two queries:

1.       While going through the NDK documentations, I found, in "STANDALONE-TOOLCHAIN.html", that this is possible to compile my source as is (as far as build method is concerned) using the "arm-linux-androideabi-4.4.3" cross compilation – this will help me as I need not to change my makefiles etc. However, the standalone tool is still in "BETA".  Is there any plan for the final release of the standalone toolchain as GA.?  If no, then what best I can do? (I think it would be "ndk-build.sh"– And android style makefiles i.e. Android.mk).

2.    My library, which is in C as mentioned previously, needs to fetch some hardware level details like IEMI number of mobile device – which   means I need to use(probably) "TelephonyManager" interface from inside my C code. Would this be portable or is there any other (stable API/ABI) available to do so in Native code (i.e. C).

Merry Christmas & Happy New Year!

-Raman

[David Turner]

On Fri, Dec 23, 2011 at 9:29 AM, Raman Chalotra <ramanc...@gmail.com> wrote:

Hi All,

I have been trying to port few libraries from Linux to Android. The source code is in C and build procedure is GNU style Makefiles. So, I need to use the NDK. The user of my library will be writing application in JAVA (as is obvious on Android).

I have few two queries:

1.       While going through the NDK documentations, I found, in "STANDALONE-TOOLCHAIN.html", that this is possible to compile my source as is (as far as build method is concerned) using the "arm-linux-androideabi-4.4.3" cross compilation – this will help me as I need not to change my makefiles etc. However, the standalone tool is still in "BETA".  Is there any plan for the final release of the standalone toolchain as GA.?  If no, then what best I can do? (I think it would be "ndk-build.sh"– And android style makefiles i.e. Android.mk).

It's not in beta anymore. Please disregard this label, and feel free to use the standalone toolchain. I'll fix the documentation.

 

2.    My library, which is in C as mentioned previously, needs to fetch some hardware level details like IEMI number of mobile device – which   means I need to use(probably) "TelephonyManager" interface from inside my C code. Would this be portable or is there any other (stable API/ABI) available to do so in Native code (i.e. C).

There is no native API for this, which means you will need to call framework APIs through JNI to achieve this.

Hope this helps

 

Merry Christmas & Happy New Year!

-Raman

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[David Turner]

On Fri, Dec 23, 2011 at 1:03 PM, David Turner <di...@android.com> wrote:

1.       While going through the NDK documentations, I found, in "STANDALONE-TOOLCHAIN.html", that this is possible to compile my source as is (as far as build method is concerned) using the "arm-linux-androideabi-4.4.3" cross compilation – this will help me as I need not to change my makefiles etc. However, the standalone tool is still in "BETA".  Is there any plan for the final release of the standalone toolchain as GA.?  If no, then what best I can do? (I think it would be "ndk-build.sh"– And android style makefiles i.e. Android.mk).

It's not in beta anymore. Please disregard this label, and feel free to use the standalone toolchain. I'll fix the documentation.

 

I have not seen any mention of "BETA"/"beta"/"experimental" in the latest NDK documentation, so I guess it doesn't need fixing. Let me know if there is still something in the doc that leads you to believe that this is the case, and I'll correct it.