appcompat(v7) library gets add up automatically when you are using a minimum API level for your application development. Why am I getting appcompat with API 11? I mean if its already included in API level 11 why does it add up then. Can and should I remove it?
Related
My library project has a location service, and per Android Q requirements it sets the android:foregroundServiceType="location" attribute in the manifest. When an app module uses my library and compiles against API level 28, it fails with the following error:
AndroidManifest.xml:57: AAPT: error: attribute android:foregroundServiceType not found.
How can my library maintain compatibility with older versions, while making sure the functionality works on Android Q?
I had same error and after migrating to Androidx and updating compileSdkVersion from 28 to 29 my issue was resolved. So please do these changes and you can get your solution
My goal is to avoid breaking anyone's build when the library version is updated, and at the same time avoid forcing the developer to compile against API 29. It seems I have two choices:
Provide a separate library so that developers compiling against API 28 and lower don't get impacted;
warn developers targeting the new version to replace the service definition in the manifest using tools:node="replace".
The problem with the first approach is that I will need to maintain two libraries for some time. The problem with the second is that developers must remember to revert the change once they update the SDK version.
In my case, I will go with the second approach. By passing an explicit foreground service type to the startForeground method when targeting Android Q, I can cause a crash if the type is not set in the manifest. The developer can therefore catch this when targeting Android Q and revert the manifest change to fix it.
I've used the below code in my application.
getActionBar().setHomeButtonEnabled(true);
I've set
android:minSdkVersion="11"
in my code. However, every time I edit my AndroidManifest.xml file, it gives an error.
Call requires API level 14 (current min is 11):android.app.ActionBar#setHomeButtonEnabled.
And error disappears after cleaning the project (in Eclipse).
Project -> Clean..
Is there a fix without having to clean the project everytime?
The ActionBar class was added in API level 11, but not the method your are using. If you look at the doc you'll see that setHomeButtonEnabled(boolean) was added in API level 14.
Yes, add action bar sherlock as a library. it allows you to work with API 8 and above.
https://github.com/JakeWharton/ActionBarSherlock
Also while using actionbarsherlock, the code should be :
getSupportActionBar().setHomeButtonEnabled(true);
The android doc here states that I can target Api Level 8+ devices and still specify that I want to use the Holo theme for devices that are API Level 11+. I should be able to do this using two themes.xml files :
One would go in /Resources/values for devices of API Level 8, 9 and 10
One would go in /Resources/values-v11 for devices with API Levels 11+
In a Xamarin.Android project, using Xamarin Studio it doesn't look like it's working, I get a compile time error :
Error retrieving parent for item: No resource found that matches the given name '#android:style/Theme.Holo'.
Am I doing something wrong here ? Is there a workaround ?
Theme.Holo is only available on API 11 and above.
If your project target is set to automatic, the system will build against the minimum level required (I think).
Try explicitly setting it to a higher API version.
Can anyone explain regarding the Minimum Required SDK, Target SDK , Compile with options while creating an application.
If i set the minimum required SDK as API 8, Target SDK as API 16 and Compile with API 17,
will it work on Froyo devices in adroid?
If i want to use the methods introduced in API 16 or Library uses API 16, and want my app
to work on Froyo or ICS devices, how can i achieve this?
Thanks in advance.
You can use API-Level 16 methods only on devices that are Level 16 and higher. But you can check in your app and only call them when this is the case. Look into my small test-app which uses API-11-methods and runs from API-3 and up.
http://code.google.com/p/android-change-log/source/browse/trunk/src/sheetrock/panda/changelog/ChangeLog.java
Look at lines 40-41, 144-145 and 324-341. You don't need any third party libraries for this, but you need to put your higher API code in a separate class (lines 324-341).
Yes. But be careful not to include API higher than Froyo in your application
From my understanding, you can't, unless you use third party libraries. There are useful libraries out there which help you realise that:ViewPager and ActionBarSherlock.
Yes ofcourse for first question. If you use like this.
android:minSdkVersion="8"
android:targetSdkVersion="16"
For second. you can go for third party library if you import it, surely will work.For eg:
special features introduced in android 4.0 with tabs and swipe.But to overcome that
actionbar sherlock library been introduced which support in all version and in github.
Hope it helps you.
I have a App created on API 8. Now I want to make it work with ICS and for that I need additional imports which are not available in API 8.
I want to add following imports:
import android.provider.CalendarContract;
import android.provider.CalendarContract.Calendars;
import android.provider.CalendarContract.Events;
So do I have to make a diffenent app just for API > 15? The name of the App should not change.
Or maybe it is possible to place 2 App versions and make the minSdkVersion and maxSdkVersion according to the API level into Google Play?
How do you handle that?
I have a App created on API 8.
Great!
Now I want to make it work with ICS and for that I need additional imports which are not available in API 8.
No problem! Since import statements are applied at compile time, so long as you set your project's build target (e.g., Project > Properties > Android) to API Level 14 or higher, your code will compile fine.
So do I have to make a diffenent app just for API > 15?
No. Just use version guard blocks to ensure that you do not try using the newer code on older devices:
if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
// do stuff with CalendarContract
}
Or maybe it is possible to place 2 App versions and make the minSdkVersion and maxSdkVersion according to the API level into Google Play?
That should not be necessary.
You want to add a compatibility shim to your existing app so that it works on lower API levels and is still able to access API's from higher levels.
In general, the way to do this is to isolate the code that uses the higher-level API's in classes that are loaded at run-time via reflection, only if the API level supports them.