Is it possible to discover the API level in JNI_OnLoad?

[Carlos A. M. dos Santos]

Hi,

I'm writing a DLL that needs to perform different initialization steps
in JNI_OnLoad, depending on the system API level. Currently I'm using
JNI calls to get the value of android.os.Build.VERSION.SDK_INT, but I
wonder if it could not be made in a simpler way. Any suggestions?

Thanks in advance.

--
"The flames are all long gone, but the pain lingers on"

[H B]

Yes. In your jni code, include "sys/system_properties.h" and then call __system_property_get for example:

char value[93] = "";

__system_property_get("ro.build.version.sdk", value);

...to retrieve the value of the sdk version on the current device. *Technically* that property could change name in a later version of android, which is why the android.os.Build.Version class abstracts that away so you normally wouldn't notice.

[Dianne Hackborn]

That is not a published API, so you can not assume it will work across all devices or versions of the platform.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/-JA2t61J9EMJ.

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.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Carlos A. M. dos Santos]

On Mon, Aug 15, 2011 at 6:27 PM, Dianne Hackborn <hac...@android.com> wrote:
> That is not a published API, so you can not assume it will work across all
> devices or versions of the platform.
>
> On Mon, Aug 15, 2011 at 1:55 PM, H B <hbls...@gmail.com> wrote:
>>
>> Yes. In your jni code, include "sys/system_properties.h" and then
>> call __system_property_get for example:
>> char value[93] = "";
>> __system_property_get("ro.build.version.sdk", value);
>> ...to retrieve the value of the sdk version on the current device.
>> *Technically* that property could change name in a later version of android,
>> which is why the android.os.Build.Version class abstracts that away so you
>> normally wouldn't notice.

Ok, but just out of curiosity, why is sys/system_properties.h
distributed with the NDK if that is not a published API?

[Tim Mensch]

On 8/15/2011 8:45 PM, Carlos A. M. dos Santos wrote:
> Ok, but just out of curiosity, why is sys/system_properties.h
> distributed with the NDK if that is not a published API?

Dianne, he's right. It's not in linux/ or asm/, so according to STABLE-APIS.html, it should be supported. I was going to point him at that STABLE-APIS, only to be reminded that sys IS in the supported column, and that I'd had this problem with some of the atomic APIs as well, which David Turner (IIRC) told us were going to change.

In the latter case, after I mentioned that it was in sys/, David changed his original position and told us yes, since it's in sys/, it is documented to be supported, and that future development would need to keep it stable. I would like to think that we can trust the STABLE-APIS docs moving forward.

Now I do get that the PROPERTY NAME might change later (as H.B. mentioned), or that the function could potentially start returning empty strings for all keys or some such, but shouldn't we be able to trust STABLE-APIS.html?

Tim

[David Turner]

What Dianne means is that the values of the system properties are not a stable API.

Also, we might want to restrict access to system properties in the future for security reasons. I can't give you details, but don't expect this method to work 100%

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.

[Dianne Hackborn]

Right the fact that you are putting a magic string value in your code is a big red warning sign that you are using magical internal values that are not part of the official supported API.

[Tim Mensch]

On 8/16/2011 8:26 PM, Dianne Hackborn wrote:
> Right the fact that you are putting a magic string value in your code
> is a big red warning sign that you are using magical internal values
> that are not part of the official supported API.

Cool, fair enough.

I was just worried since H.B. did say that the string could change or
the function could stop returning anything in future Android versions in
his post.

Tim