Artifact used (androidx.textclassifier:textclassifier:1.0.0-alpha02):
Version used:1.0.0-alpha02
I am working on an app which is based on TextClassifier. In order to support back-port on API 14 - 27, I use the AndroidX's TextClassifier, however, what disappointed me is that the predicting results of the NONE-P devices (API 14-27) are different from API 28 which is Android P. I figure out that internal of AndroidX is using the ">=P" for different solution which means, on 28, the library uses native ML solution (maybe).
i.e:
to predict the date-time text which is selected or passed into the app.
On Android P:
July 20, 1969, at 20:17 -> inference: date or DateTime and the score: 0.9897
<= O:
July 20, 1969, at 20:17 -> inference: other and the score: 0.9897
Is there any idea to let AndroidX's TextClassifier more AI-strong, like native Android P?
Issue
Related
I followed this page: https://developer.android.com/about/versions/13/setup-sdk
to set up Android 13 SDK.
In my build.gradle:
android {
compileSdkVersion("Tiramisu")
defaultConfig {
targetSdkVersion("Tiramisu")
}
}
Then I got the error:
> Unsupported value: Tiramisu. Format must be one of:
- android-31
- android-31-ext2
- android-T
- vendorName:addonName:31
I tried to use "33" instead of "Tiramisu", but it's not working.
I'm using the latest Android Studio Preview as the instruction.
Is there anyone trying to use Android 13 SDK?
This answer is no longer valid because you can use API version 33 now for Tiramisu as it's officially released
Credit to #NickolaySavchenko - Posting this answer since I've been waiting for him for a day.
Finally, after taking advice from #NickolaySavchenko - I have a final working code like this.
compileSdkVersion "android-Tiramisu"
targetSdkVersion "Tiramisu"
Yes, you see it correctly, the targetSdkVersion is Tiramisu, not android-Tiramisu so that it can run in an emulator API Tiramisu device.
I tested and can confirm that minSdkVersion doesn't need to change to android-Tiramisu or Tiramisu. I'm still keeping it as 19 and it's working great.
As #NickolaySavchenko said
compileSdkPreview "android-Tiramisu"
targetSdkPreview "android-Tiramisu"
working fine
and to run it on android 13 you also need to change your minSdk to "android-Tiramisu"
How to refer aosp hidden methods in core android app using gradle build system. I am referring framework and other jars from out folder but unable to access hidden API. Is there any way to access hidden methods.
There are a couple ways.
Android Hidden API
As long as you're fine targeting API 27 (there's no API 28 release as of writing this) this way works great. You can directly call the hidden methods with proper code completion and everything.
Note: As of writing this, you'll need to set your Gradle classpath to 3.1.4. 3.2.0 adds some sort of integrity check that breaks builds when using a modified framework JAR.
Use reflection
It's not ideal, but it'll work if you want to target API 28, or you want to use Gradle 3.2.0.
Example (Kotlin):
val IWindowManager = Class.forName("android.view.IWindowManager")
val IWindowManagerStub = Class.forName("android.view.IWindowManager\$Stub")
val ServiceManager = Class.forName("android.os.ServiceManager")
val binder = ServiceManager.getMethod("checkService", String::class.java).invoke(null, Context.WINDOW_SERVICE)
val iWindowManagerInstance = IWindowManagerStub.getMethod("asInterface", Binder::class.java).invoke(null, binder)
val hasNavBar = IWindowManager.getMethod("hasNavigationBar").invoke(iWindowManagerInstance) as Boolean
I am adding the Butterknife library to my Android application. What is the the minimum Android version it works well on, or does it work well with all versions of Android?
The minSDK is 14. Check it here - https://github.com/JakeWharton/butterknife/blob/master/build.gradle
ext.versions = [
'minSdk': 14,
'compileSdk': 27,
'supportLibrary': '27.0.2',
'androidPlugin': '3.0.1',
'androidTools': '26.0.1',
'kotlin': '1.2.10',
'release': '8.8.1', ]
And usage here:
https://github.com/JakeWharton/butterknife/blob/master/butterknife/build.gradle
I'm curious about what is the sense in setting both target and minimal supported API version when starting a new Android Studio project. I mean, if I set that minimal API is, say, 8, then I won't be able to use features from 22 (which could be my target), because it would break compatibility with API 8.
if I set that minimal API is, say, 8, then I won't be able to use
features from 22
You can use API level >= 8 features in application, but you have to check OS version of the device first, see following code, that's how you can maintain compatibility
if (android.os.Build.VERSION.SDK_INT == android.os.Build.VERSION_CODES.HONEYCOMB){
//use features of API 3.0
} else if (android.os.Build.VERSION.SDK_INT == android.os.Build.VERSION_CODES.HONEYCOMB_MR1){
//use features of API 3.1
} else if (android.os.Build.VERSION.SDK_INT == android.os.Build.VERSION_CODES.HONEYCOMB_MR2){
//use features of API 3.2
}else{
// and so on....
}
Other then code, use can use resource folders on the basis of API level, like:
values-v11
values-v12
values-14
....
and
drawable-v11
drawable-v12
drawable-14
....
This is not correct. By setting target API to 8 you can't use any features added after, but specifying minimum API is just a guarantee that you application will work on such devices. You don't guarantee that it provide all features on such devices, nor minimum API level restricts what features it could use when running on later versions of OS.
Look at PE history - all win32 executable files are compatible with MSDOS, but all they say after executing is just "This is not a MSDOS program.". Similar to this, it is your decision what features you provide on which OS you support.
I am working with a large project, which has a minimum API level:16. however, I came across API usages that are above API level 16.
Is there any tool in Android studio or elsewhere, other than testing with a device, to check if the code doesn't violate the minimum required API level or better point it out like an error etc.?
Thank you.
The IDE will use the minimum android SDK, thus you will not get compile errors. If you there are classes in SDK 14 which are moved in sdk 16, yet you are using the imports from SDK 14, it will give a standard compile error.
So no, not that I am aware of.
You can use something like this:
public static boolean supports(final int version) {
return Build.VERSION.SDK_INT >= version;
}
Like this,
if (supports(Build.VERSION_CODES.HONEYCOMB)) {
// do something HONEYCOMB+ compatible here
}
More codes here,
http://developer.android.com/reference/android/os/Build.VERSION_CODES.html