I have a piece of code (actually a library I'm including) that only functions correctly using KitKat MR2 (4.4.3).
The other MR seem to have to their own API versions in Build.VERSION_CODES, but I can't find any way to target 4.4.3 and above using the SDK_INT. Should I just use the incremental String field and do a String comparison?
// the "easy" (wrong) way
if(Build.VERSION.SDK_INT >= BUILD.VERSION_CODES.KIT_KAT) { // but that includes 4.4, 4.4.1, and 4.4.2!
}
// the "hard" way
if(compareVersionCodes(BUILD.VERSION.RELEASE, "4.4.3") > 0) { // implement some comparison function for the version codes instead
}
Is targeting KIT_KAT acceptable -- meaning is this something like version 14 vs 15 where everyone automatically gets the higher version?
I can't find any way to target 4.4.3 and above using the SDK_INT
The API levels are for changes in binary compatibility -- stuff like new classes, new methods, etc. They aren't for bug fixes, other than to the extent such fixes break binary compatibility.
Should I just use the incremental String field and do a String comparison?
That's not awesome, but unless there's some way you can interrogate the Bluetooth LE APIs to see whether or not you're on a malfunctioning device, you may need to go this route. However, later this year, I'd set up the check algorithm to be more like:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.WHATEVER_THEY_CALL_L ||
(Build.VERSION.SDK_INT == Build.VERSION_CODES.KIT_KAT && getPatchLevel()>=3)) {
// do your thing
}
where getPatchLevel()
tries to use RELEASE
to find the patch level and fails gracefully if RELEASE
is not of the form XYZ This approach will handle both the 4.4.3/4.4.4 scenarios and whatever the numbering is for the next Android version.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.