I recently started Androids Studio, I bought a quiz game and I tried to modify it a bit with the help of some tutorials, only when I want to generate the apk I get some errors, I tried to do everything from the beginning about 10 times and the same, I don't know where I'm wrong, you have below a link with a video with the errors. Thank you in advance!!!
https://www.youtube.com/watch?v=59fxv4F5DYE
I guess you are getting an error due to using Vector drawables which are supported on Android API 21 and above and your minSdk is lower than 21. The solution to this is either update your minSdk version to be at least 21.
Or in your gradle.build:
android {
defaultConfig {
vectorDrawables.useSupportLibrary = true
}
}
And in application class define this:
#Override
public void onCreate() {
super.onCreate();
AppCompatDelegate.setCompatVectorFromResourcesEnabled(true);
}
And when using the resource for example in your ImageView:
<ImageView
...
app:srcCompat="#drawable/ic_some_vector" />
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"
In a build.gradle, we have the android block. From my limited understanding of Android Gradle Plugin (and Groovy/ Kotlin), this is a method/ (or function?) called android which accepts 1 argument, a closure.
android {
compileSdkVersion(AppConfig.compileSdkVersion)
buildToolsVersion(AppConfig.buildToolsVersion)
}
I was not able to find any documentation about android, both on the Google Developer website and Gradle.org. It doesn't help that the function has the same name as the whole operating system. Any documentation about Android Gradle plugin would be helpful, as it seems like information about it is pepperred all over Android docs. So far, I can search what each property means (e.g. applicationId, testInstrumentationRunner), but I want to see all the properties which android has, which is where the documentation comes in handy.
What sparked all these questions was this "Introduction to Groovy and Gradle"
I was able to get the "package name" (maybe) for the android method with autocomplete in Android Studio: com.android.build.gradle.internal.dsl.BaseAppModule, but cannot find source code or documentation...
It is described in android gradle plugin documentation under the class name AppExtension. Here's a link //google.github.io/android-gradle-dsl/3.3/com.android.build.gradle.AppExtension.html
Please note that the android keyword mentioned in your question is not a function / method.
The android { } is an android block is where you configure all your Android-specific build options.
Also, as of now there is no specific document dedicated to this block.
However, just to assist you, I have identified following attributes which can be placed inside this block.
android {
compileSdkVersion 30
buildToolsVersion "30.0.2"
defaultConfig {
}
buildTypes {
}
compileOptions {
}
kotlinOptions {
}
packagingOptions {
}
}
I am working on a project with minSdkVersion set to 25 (aka Android 7.1).
Since this version is quite high, there are a lot of methods I can use without worrying about backward compatibility.
For example, retrieving a drawable, from a Fragment, should be as simple as:
context?.getDrawable(R.drawable.my_drawable)
In the source code, what it does is:
return getResources().getDrawable(id, getTheme());
As far as I am concerned, such a method was introduced in API 21 (Android 5.0).
However, I get the following warning:
Looking at the source code of ContextCompat.getDrawable(...):
if (Build.VERSION.SDK_INT >= 21) {
return context.getDrawable(id);
} else if (Build.VERSION.SDK_INT >= 16) {
return context.getResources().getDrawable(id);
} else { ... }
Since the min SDK is set to 25, the first if will always be called, which then the same code I have written. So why the warning?
I could suppress it with the #SuppressLint("UseCompatLoadingForDrawables") but it kinds of defeat the purpose... or I could follow it...
Is this normal? Should I really use ContextCompat and its affiliates or is there a setting somewhere to remove such a false warning?
PS: the project is also using Android X.
Ran into the same issue. I would say it is a false positive when you have a minSdk >= 21. Since as you say you will always enter the if branch which calls getDrawable.
So suppressing/ignoring it is the way to go until someone can make the lint rule smart enough to detect that you are on minSdkVersion higher than 21. You can ignore it globally by doing this in your build.gradle:
android {
...
lintOptions {
ignore("UseCompatLoadingForDrawables")
}
}
Interestingly context.getColor(R.color.something) does not give a similar warning even though it has similar code in ContextCompat.getColor.
I use openOptionsMenu() to open the menu in applications with special GUI - for example, apps that only show graphics (fullscreen apps without toolbars etc.), upon a long press of the screen.
I can see that I made it work in the past on other applications, and I suppose that it was by using in the Manifest,
android:minSdkVersion="15"
android:targetSdkVersion="15"
I am now unable to make this work (the code would be):
myButton.setOnLongClickListener(
new OnLongClickListener() {
#Override public boolean onLongClick(View v) {
openOptionsMenu();
return false;
}
}
);
I think that Android Studio is using the wrong SDK. In fact,
the values I put in the Manifest ("min" and "target" set to 15) are overridden;
the values used should be those of build.gradle - and again, I set "compile", "min" and "target" set to 15, but I do not see the app
working properly and I think the SDK selection may not be happening;
as I check the produced APK the Manifest entries for the SDK (minSdkVersion, targetSdkVersion) are missing.
The build.gradle file according to the Android Studio interface shows:
android {
compileSdkVersion 15
buildToolsVersion "28.0.2"
defaultConfig {
applicationId '[...AppID...]'
minSdkVersion 15
targetSdkVersion 15
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
}
}
productFlavors {
}
}
As written above, the AndroidManifest.xml in the compiled APK (after apktool -d) does not mention any SDK selection.
I expect that the app compiled for SDK 15 would open the (very required) menu upon call of openOptionsMenu(). What the compiled app does now, upon debugging, is to go instead in the method that would /close/ the menu (clearly a satanic intention).
EDIT: the information about the specific case of Google butchering openOptionsMenu() after some SDK version is at
openOptionsMenu function not working in ICS?
I suppose I have made a mistake.
I realized that my past, working code did not just compile for SDK 15, it also contained an override as follows, and as suggested by user tallicalord in the previously linked page:
#Override public void openOptionsMenu() {
Configuration cfg = getResources().getConfiguration();
if( (cfg.screenLayout & Configuration.SCREENLAYOUT_SIZE_MASK)>Configuration.SCREENLAYOUT_SIZE_LARGE){
int shelf = cfg.screenLayout;
cfg.screenLayout = Configuration.SCREENLAYOUT_SIZE_LARGE;
super.openOptionsMenu();
cfg.screenLayout = shelf;
}else{
super.openOptionsMenu();
}
}
So it is possible that the SDK selection, even though more mysterious in Android-Gradle (which removes references in the Manifest), was not the problem.
I shall note that it is very unfortunate how Google manages to make people waste uncountable hours for problems that did not need to exist at all.
i have successfully made a project apk which allow the watch download the wear app. And i am trying to use that wearable code to support standalone for wear 2.0 as well - seem not much resources in the internet.
my question is how to determine if the wearable device is 1.0 or 2.0. i made use of productFlavors based on this link as follows:
android {
// Allows you to reference product flavors in your
// phone module's build.gradle file
publishNonDefault true
...
defaultConfig
{
// This is the minSdkVersion of the Wear 1.x embedded app
minSdkVersion 23
...
}
buildTypes {...}
productFlavors {
wear1 {
// Use the defaultConfig value
}
wear2 {
minSdkVersion 25
}
}
}
As i recalled, wear 1.0 usually collect data from phone and wear 2.0 has ability to access data via the internet. Please correct me if i am wrong.
So if the wearable is 1.0, it uses Wearable.API and sync with the phone. Otherwise, the wearable sync with cloud.
I had a look on this post which seems useful but i do not quite understand.
PackageManager pm = getApplicationContext().getPackageManager();
pm.getPackageInfo(packagename, PackageManager.GET_ACTIVITIES);
Should i set a different packagename(or applicationId) for wear2 so that i can use this method?
is there any drawback when i put standalone version on play store? i suppose i have to create a new project in this way.
Please can anyone advise the best way to achieve my purpose?
If you want to distribute and maintain two separate APKs, then the build flavor is probably a reasonable way to go. But I would suggest that this won't be a good experience for either you or your users; it's more work for you, and it'll be confusing for them (which version do I install? why doesn't this app work after I my watch upgraded to Wear 2.0? and so on).
My suggestion would be to put it all in one APK, and simply choose which sync technique to use at run time:
if (Build.VERSION.SDK_INT < 24) {
// Wear 1.x
} else {
// Wear 2+
}