Next Tutorial
Android RJava and BuildConfig Java
Prev Page
View- All Tutorials
AndroidManifest.xml
Tutorial 1
The code in these free Android tutorials is compatible with AIDE - the free Android App for Creating Android Apps.
The programming language is JAVA XML.
AndroidManifest.xml, is a file that basically gives an overview of what is included in the android application including required app components. Some elements within the manifest are required while others are optional; you add them if your app requires them. Structure of the Manifest File
The manifest file contains important app details like the app package name, the apps first activity name, application particulars, and intent declarations.
The Manifest file has a xml extension...this file is created automatically when you create your template app and it updates each time you build and run the app code. This file can and may need to be edited when adding certain elements or removing elements from the app code.
Certain elements must be included in this manifest file or your app will not launch or run.
Activity Element
Your app must have at least one activity.
The activity is considered a necessary app component, because without it, your app would not run nor could you add additional coded pages to your app.
One activity is like one screen view; you can have an app with just one activity or several.
And the first activity of your application must have an intent filter included. This is also declared in the androidmanifest.xml.
This intent filter communicates to android system to launch the first activity. Any additional activities you add are linked from this first app activity.
Intent Filter Element
The intent filter is required in order to activate the first activity within the app.
The intent filter also links your first activity to any additional activities your app may have.
If you do not use an intent in the manifest file, then your app will not launch the first activity screen, or view; (usually containing text, buttons, images, menus)
View all elements of Intent Filter
To locate this file in your android app project files goto:
AppProjects/nameOfApp/AndroidManifest.xml
nameOfApp is the name you gave the app when you created your appProject
In each activity you can add a Text View which allows you to add text to the screen. You can also add ImageView, Buttons; whatever widget you want can be added. Like a webpage; which has text and images and buttons.
You can also add more widget elements like menus, radio buttons,nav bars, and toolbars.
So you want to target previous platforms as well as the newer platforms with an api number.
You also want to set the correct api, especially if you added any 'code classes' that require them; both for performance and compatibility.
Setting the proper api ensures your app performs as you want it to on the highest api target you define. This same target must adhere to any libaries(dependencies) you add to provide for compatibilty; not only on newer platforms; but making the code perform as you want it to on older android platform versions as well.
To do this, you set a min SDK and a Target SDK. The min SDK is the lowest version you want to app to be compatible with and the target SDK is the highest version you want your app to be compatible with. This target should also be the version you have tested your app on ensuring it is market ready.
As an android app developer you can use whatever SDK versions you want. These are the recommended versions to use to reach the largest market of android smart phone/ tablet users.
And, making your app most compatible with older android versions.
If you do not set a min SDK, android uses version 1 as the API.
As an app developer, you want your app to be downloaded and installed by as many users as possible. Setting your APIs correctly is good practice to reach your potential markets.
If your not adding newer classes nor want to target the most up to date android platforms, then you do not have to change them. If your developing apps to submit to app stores like Google, Amazon; then most likely you want your app to be up to date with most recent api version.
For example, if your using a code class whose required API is 25, and you use API 24 as your target SDK, you will get app errors because the target must be the same or greater than the code class api number.
In this case, you would change the target SDK to 25, and then your code in the app would be fine; or the Target SDk can be equal or greater than the Code Class in the app but not less than it.
The dependency itself is just one or more lines of code. It is added to the build gradle at dependencies as shown in the build gradle image on this page.
Once you add the code; you Save the page and the dependency library is added to the app project. The libraries code is downloaded to your app from a 'respository'. This usually takes a few seconds once you click 'Save'.
When you begin adding more sophisticated widgets and features from more recent platform versions then setting the APIs correctly, and adding the recommended dependencies is more important.
In our tutorials, we use a template app, and it adds the latest min and target SDKs for us. So, this is not something we must change, unless, we are adding some specific code class that require dependencies, and specific api number to match it. But for our tutorials, all codes and platform numbers are given with each tutorial.
FYI - Build.gradle, Target SDKs
If your using the newest edition of AIDE, the Min SDK, and Target SDK are now coded in the build.gradle of your app project. Previously they were coded in the AndroidManifest.xml.They can be coded in either app project file, but it is best practice to code them in build.gradle; and if they are in both pages; the android system will preference the targets shown (coded) in the build.gradle.
Targeting with The Latest Version/API
Android version 14 is the latest platform os; this is api 34. With any new apps you develop, your SDKs should be targetting newer platforms and you should be testing/installing your apps on these as well, if possible. Most of us have newer phone models, so long as it is not ancient, your apps will work fine.
Using SDK target of 31, 32, 33, 34 is now recommended. And, for min SDK, use 16 - 23.
To set your Targets; goto your build.gradle at app module, as shown in this image.
Example:
Just change the SDK to api 16 - 24 for min; and to api 34 for target.
In each app you create; check the Code Class api, then check your defaultConfig at the build gradle page, to ensure the SDKs for min, target, compile; and build tools is set properly.
FYI: Each app you create actually has 2 build gradle files; and also a 'settings gradle'. One has the SDK targets, and dependencies code; the other has the build code for the repositories. Both can be edited. The 'settings gradle' is not edited. (shown at the build gradle image and at Example Code section).
The SDK target build version and compile api number must be the same if your using a 'code class' that is available only in the target that you set. And, in this case, the SDK for compile and build tools must match; Example, SDK Compile version api 28 is build tools number 28.0.3
Otherwise; the SDK compile version can be less than the SDK target number.
As of 2023, the latest build version is 34.0.0
View this link for 'build tool numbers:
Build Tools by Platform Releases- Android
The SDK target is also used for testing purposes for your app build.
So, for example, if you use SDK target 28 (api 28); means you have installed the app on an android smartphone or tablet that has android version 9(which is api 28). Because you have installed it on android 9, you know you can use that as your target SDK version.
For our tutorials, some apps were built on android 4, some on 5, and Tutorials IIII, mostly android 6. Most apps developed on android 6 were also installed on android 9. It is easy to test your new app; just install the .apk file on any android device it is targetted for; if it installs and opens without issue then it is good.
And, you don't have to develop your app on the latest versions, but it is a good idea to install your app on a newer version of android.
If your making apps with Android Studio, you can use its' 'emulator' to test your new app.
You should test your apps on your target SDK before publishing them at app stores or your own website. This way, you know it was tested and performed as it should on that device (particular android platform).
For our tutorials, we will include the specific (SDKs) for any app that requires them. The build gradle code will be added at the Example Code section for the app tutorial; with details included. Min and target SDKs are also included with each app tutorial.
If you need to add 'dependencies' for an app tutorial, that code will be included also with the Example Code; with details included.
How to Implement Dependencies
As stated previously, dependencies are 'code libraries', that are added to your app code to make it compatible with older android version(platforms). Whether you include them is your choice; however, including them makes your app accessible to more android users. So, if your developing android apps to submit to the app stores; you would probably want to include the libraries.
Libaries are coded at the 'dependencies' section in your app's build gradle.
When adding a dependency you add it at dependency in this page; and you check also; the SDK compile version, SDK build tools version, SDK min version, and SDK target version.(see build gradle image this page)
These most likely have to be edited with api numbers that correspond the dependency library your going to add.
Like android platforms, the dependency libraries(aka- support libraries) are continually being updated with new code classes and as such new release numbers.
Also introduced in Material Design were Graphics with Vectors, and Material Color Blends.
View Material Design Components
All these new Material Design code class components require a SDK target of at least 21, SDK compile version 21, and SDK build tools version of 21.0.0.
Coded as such on an android device with at least platform 5; your app should build and test without issue on this device that built it.
Now, lets suppose we want to install that same app on android version 4. which is api 20. As the app is now, (code wise), it might install, but the app cannot perform as intended because it does not have any code included to 'support the Material Design Components'.
For a specific Material Design component (example), lets use CardView.
The support libraries as previously mentioned, are just a bunch of code packaged together and presented as a 'support library', for whatever code class it supports.
We, as a developer, choose the library we require for the code class we are including in our app.
In this case; our widget (CardView); we get the support library info(usually just a line of text with numbers at the end, see Example Code section for example dependency) and copy paste that into our build gradle at the dependency section.
Then we save the page; and the required library is downloaded from the web into our App Project.
App Project Name / build gradle. The App Project / app / build gradle is the other build gradle where we set our SDKs and add dependencies. This one is known as 'app module level build gradle'. You can easily browse your app projects in AIDE to view and learn about these pages.
As mentioned, these default libraries are included for us in our template app we use to make our new apps. It is good to learn what they are and what they do.
Now, our app can be installed on Android version 4 and will perform as it should.
You can now submit your app apk for publishing at app stores. In this scenario example; you would use Android Version 21(platform ver 5) as your target api; because that is the highest api version your app was tested on.
Android platform code classes are compatible with newer platforms but not usually with older ones. So for our CardView example; with a SDK target version of api 21; it will install and perform as it should on api 21, 22, 23, 24, 25 - 34(platform 14).
Ideally; for the current year, you would most likely use and test(or install your app) on newer platforms or for desktop use the Android Studio emulator for testing.
We used the Material Design CardView as our Example; so we used 21 as our SDK version target. You can set a higher api. You cannot set a lower SDK target than 21 when using the CardView widget.
Android added with Material Design the appcompat support libraries. These are now a few years old but until recently were updated on a regular basis to include new codes or updates to improve existing ones.
Each new update of a support library like 'appcompat', gets a new update number, aka release number. These are usually incremented from the previous release and that number is included with the support text, usually a line of coding, which you add to the code at build gradle. The library code begins with the word implementation followed by the code itself: implementation 'androidx.cardview:cardview:1.0.0', and the last numbers are the version or release of the dependency.
This is the support library code for Material Design 'CardView', from the androidx support libraries.
implementation 'androidx.cardview:cardview:1.0.0'
This is the support library code for Material Design 'CardView', from appcompat support libraries.
compile 'com.android.support:cardview-v7:+'
Compile is no longer used, it is replaced with the world implementation for each dependency you add.
Android X Libraries
Androidx was introduced in android version 9, api 28. As of androidx, api 28, the appcompat libraries are no longer maintained. It is recommended now to use 'androidx' support libraries for new apps you develop. Androidx is api 28.
This means when you include code or libraries from 'androidx', you must use api 28 as your SDK target. If you use less than api 28, your app will not build; or app will not open.
Usually, you get error messages when you Run your app if your SDK target is not set correctly.
Additionally, because you are using 28 as the 'target SDK", you must also set your SDK 'compile version' to 28, and because your compile version is 28, you must set your 'SDK build tools version' to match your compile version;
Code them as:
SDK target version 28,
SDK compile version 28,
SDK build tools 28.0.3,
The build tools versions are at Android Developer website; as are Support Libraries and Api and Platform Releases.
This represents the older versions you want your app to be compatible with. For this, you want to determine how many devices are using a particular android version and is it a market you want for your app and its' features to target.
At this time, android APIs 14 and 16 have about a 5% share of android devices market.
You can easily research this information with 'android device distribution world'; or similar searches.
Also Read Handling Errors in AIDE
FYI - Links
CardView Support Library
Platforms with Api and Platform Features
Material Design Components
Android View
Android - popular widgets,components
Info - Support Libraries
Android x Api Packages
Android X
Summary
As an android app developer; you can use many different code classes. Some of these are from more recent android platforms; while others may be 'standard code classes' spanning all the platforms.
With every app you create the SDK min and target version api numbers must be included in the build gradle config and also the corresponding Compile version and Build tools version.
The template app we use to make our apps already have the SDK targets included, so most of the time these do not have to be changed. AIDE updates the release information so that the build process is on par with the most recent additions to Android platform. However, if you do want to change them it is easy to do, just replace the number showing with the number you want to use. This is done in the build gradle file of your app project.
Of particular importance for setting these is:
the api of the code class your including in the app code;(is it just standard code or specialty code requiring specific api and or libraries);
the min platform you want to target.
The best way to see the features and code classes of each platform is to read the api and platform page (link at FYI links). It provides platform and corresponding api number; as well as platform highlights.
This covers the 'basics' of coding the manifest and build gradle pages in your app project. To learn more about these pages follow the included links. As you learn to code with each tutorial, you will learn all about the pages and features mentioned in this first tutorial article.
Also Read Android Developer website Manifest File Features, Conventions, Libraries.... and;
Build Gradle - adding dependencies
Android RJava and BuildConfig Java
Prev Page
View- All Tutorials
TUTORIALS l
The App PagesAndroidManifest.xml
Build.Gradle
Tutorial 1
The code in these free Android tutorials is compatible with AIDE - the free Android App for Creating Android Apps.
The programming language is JAVA XML.
AndroidManifest.xml, is a file that basically gives an overview of what is included in the android application including required app components. Some elements within the manifest are required while others are optional; you add them if your app requires them. Structure of the Manifest File
The manifest file contains important app details like the app package name, the apps first activity name, application particulars, and intent declarations.
The Manifest file has a xml extension...this file is created automatically when you create your template app and it updates each time you build and run the app code. This file can and may need to be edited when adding certain elements or removing elements from the app code.
Certain elements must be included in this manifest file or your app will not launch or run.
Activity Element
Your app must have at least one activity.
The activity is considered a necessary app component, because without it, your app would not run nor could you add additional coded pages to your app.
One activity is like one screen view; you can have an app with just one activity or several.
And the first activity of your application must have an intent filter included. This is also declared in the androidmanifest.xml.
This intent filter communicates to android system to launch the first activity. Any additional activities you add are linked from this first app activity.
Intent Filter Element
The intent filter is required in order to activate the first activity within the app.
The intent filter also links your first activity to any additional activities your app may have.
If you do not use an intent in the manifest file, then your app will not launch the first activity screen, or view; (usually containing text, buttons, images, menus)
View all elements of Intent Filter
To locate this file in your android app project files goto:
AppProjects/nameOfApp/AndroidManifest.xml
nameOfApp is the name you gave the app when you created your appProject
In each activity you can add a Text View which allows you to add text to the screen. You can also add ImageView, Buttons; whatever widget you want can be added. Like a webpage; which has text and images and buttons.
You can also add more widget elements like menus, radio buttons,nav bars, and toolbars.
View all elements of Activity
Application Element
View all application elements at:
Android Developer
Your app requires this element. Common attributes within it are icon and label . Icon is the image that is used as your app's icon;
when someone installs your app this image shows in their apps. Clicking the image launches your app. Just like any app you download to your cellphone or tablet.
This default icon is named ic_launcher. It is coded for us in the manifest when we use the template app to create our app. The image is a lttle green android. You can change this name and add your own. This is coded in the manifest at the application element.
The label is the name you used when creating your app, and shows when the app is launched.
Example LEARN FRENCH. This can also be changed in the res/strings.xml at string app_name.
Other common elements are Logo, and description. Logo is a drawable resource (image) for each activity and the app. Description is a lengthy description of the app; whereas label is a
shorter description.
There is also a package app name (known as .apk) the package name you give your app when
creating your app. This can be seen in the manifest file at the package element.
View all elements of Application
Uses SDK Element
The Uses SDK element is the version of android you want your app to be compatible with. Each android device has a platform version number; for example 4.2 is an older version while platform version 14 (api 34)
is the most recent version of android -meaning the newest android phones and tablets on the market are using android platform version 14.
These version numbers also have a corresponding API number. This API number is what is used when coding your app's min and target SDKs numbers in the manifest 'uses' element and also in the build gradle page at the 'default Config' section.
Example,
for version 4.2 the corresponding API number is 14,
for version 11 the corresponding API number is 30, and,
for 14 the corresponding API number is 34.
View this page for all Android Platforms and corresponding Apis
Android Platforms Versions and Api
Choosing Android Platform Versions
It is usually a good idea to specify platform versions prior to the current version because not everyone has the most up to date android version on their cell or tablet. Basically, you want your app to be compatible with as many android versions as possible, older and newer platform versions.So you want to target previous platforms as well as the newer platforms with an api number.
You also want to set the correct api, especially if you added any 'code classes' that require them; both for performance and compatibility.
Setting the proper api ensures your app performs as you want it to on the highest api target you define. This same target must adhere to any libaries(dependencies) you add to provide for compatibilty; not only on newer platforms; but making the code perform as you want it to on older android platform versions as well.
To do this, you set a min SDK and a Target SDK. The min SDK is the lowest version you want to app to be compatible with and the target SDK is the highest version you want your app to be compatible with. This target should also be the version you have tested your app on ensuring it is market ready.
As an android app developer you can use whatever SDK versions you want. These are the recommended versions to use to reach the largest market of android smart phone/ tablet users.
And, making your app most compatible with older android versions.
If you do not set a min SDK, android uses version 1 as the API.
Market Distribution of Platforms
Currently, android versions 8, 9, 10, 11, 12, have best market share; wheras versions earlier; 4, 5, 6, 7, have less than 7 percent share of users. Versions earlier than these are almost obsolete.As an app developer, you want your app to be downloaded and installed by as many users as possible. Setting your APIs correctly is good practice to reach your potential markets.
If your not adding newer classes nor want to target the most up to date android platforms, then you do not have to change them. If your developing apps to submit to app stores like Google, Amazon; then most likely you want your app to be up to date with most recent api version.
Adding New Code Classes
The other consideration when determining your SDK target is the code class your using in your app. All code classes have a corrresponding API. As new versions of the android os(platforms) are introduced so are new code classes. When you code you need to make sure your target SDK includes the required API of your code class.For example, if your using a code class whose required API is 25, and you use API 24 as your target SDK, you will get app errors because the target must be the same or greater than the code class api number.
In this case, you would change the target SDK to 25, and then your code in the app would be fine; or the Target SDk can be equal or greater than the Code Class in the app but not less than it.
Adding Dependencies
Also, and depending on the code classes you do use in your app; you may need to add dependencies to your app's gradle build file. Dependencies are code libraries that when included make newer code classes compatible with older version platforms. This is how android ensures all codes can work properly across all platform versions.The dependency itself is just one or more lines of code. It is added to the build gradle at dependencies as shown in the build gradle image on this page.
Once you add the code; you Save the page and the dependency library is added to the app project. The libraries code is downloaded to your app from a 'respository'. This usually takes a few seconds once you click 'Save'.
Standard Code Classes
Android has lots of code classes. Many of these are standard codes; meaning you can add them to any platform version. Usually with standard code classes you do not have to add any support libraries(dependencies) to make them compatible with older platform versions.When you begin adding more sophisticated widgets and features from more recent platform versions then setting the APIs correctly, and adding the recommended dependencies is more important.
In our tutorials, we use a template app, and it adds the latest min and target SDKs for us. So, this is not something we must change, unless, we are adding some specific code class that require dependencies, and specific api number to match it. But for our tutorials, all codes and platform numbers are given with each tutorial.
FYI - Build.gradle, Target SDKs
If your using the newest edition of AIDE, the Min SDK, and Target SDK are now coded in the build.gradle of your app project. Previously they were coded in the AndroidManifest.xml.They can be coded in either app project file, but it is best practice to code them in build.gradle; and if they are in both pages; the android system will preference the targets shown (coded) in the build.gradle.
Targeting with The Latest Version/API
Android version 14 is the latest platform os; this is api 34. With any new apps you develop, your SDKs should be targetting newer platforms and you should be testing/installing your apps on these as well, if possible. Most of us have newer phone models, so long as it is not ancient, your apps will work fine.
Using SDK target of 31, 32, 33, 34 is now recommended. And, for min SDK, use 16 - 23.
To set your Targets; goto your build.gradle at app module, as shown in this image.
Example:
Just change the SDK to api 16 - 24 for min; and to api 34 for target.
In each app you create; check the Code Class api, then check your defaultConfig at the build gradle page, to ensure the SDKs for min, target, compile; and build tools is set properly.
FYI: Each app you create actually has 2 build gradle files; and also a 'settings gradle'. One has the SDK targets, and dependencies code; the other has the build code for the repositories. Both can be edited. The 'settings gradle' is not edited. (shown at the build gradle image and at Example Code section).
Setting SDK Compile - Build Tools Versions
The SDK target build version and compile api number must be the same if your using a 'code class' that is available only in the target that you set. And, in this case, the SDK for compile and build tools must match; Example, SDK Compile version api 28 is build tools number 28.0.3
Otherwise; the SDK compile version can be less than the SDK target number.
As of 2023, the latest build version is 34.0.0
View this link for 'build tool numbers:
Build Tools by Platform Releases- Android
Testing Your App
The SDK target is also used for testing purposes for your app build.
So, for example, if you use SDK target 28 (api 28); means you have installed the app on an android smartphone or tablet that has android version 9(which is api 28). Because you have installed it on android 9, you know you can use that as your target SDK version.
For our tutorials, some apps were built on android 4, some on 5, and Tutorials IIII, mostly android 6. Most apps developed on android 6 were also installed on android 9. It is easy to test your new app; just install the .apk file on any android device it is targetted for; if it installs and opens without issue then it is good.
And, you don't have to develop your app on the latest versions, but it is a good idea to install your app on a newer version of android.
If your making apps with Android Studio, you can use its' 'emulator' to test your new app.
You should test your apps on your target SDK before publishing them at app stores or your own website. This way, you know it was tested and performed as it should on that device (particular android platform).
Adding SDKs, Dependencies
Our TutorialsFor our tutorials, we will include the specific (SDKs) for any app that requires them. The build gradle code will be added at the Example Code section for the app tutorial; with details included. Min and target SDKs are also included with each app tutorial.
If you need to add 'dependencies' for an app tutorial, that code will be included also with the Example Code; with details included.
How to Implement Dependencies
As stated previously, dependencies are 'code libraries', that are added to your app code to make it compatible with older android version(platforms). Whether you include them is your choice; however, including them makes your app accessible to more android users. So, if your developing android apps to submit to the app stores; you would probably want to include the libraries.
Libaries are coded at the 'dependencies' section in your app's build gradle.
At Build Gradle
To locate your build gradle(aka-build gradle at module level) select your App Project name, then select 'app' folder. You should now see your build gradle page. Click on it and it opens in the AIDE editor. You can make changes, then Save the page, just like any other page we edit.When adding a dependency you add it at dependency in this page; and you check also; the SDK compile version, SDK build tools version, SDK min version, and SDK target version.(see build gradle image this page)
These most likely have to be edited with api numbers that correspond the dependency library your going to add.
Like android platforms, the dependency libraries(aka- support libraries) are continually being updated with new code classes and as such new release numbers.
Material Design Components - Android Platform Version 5/Api 21
Although now not considered a newer release of the Android platform; Android Material Design, platfrom 5, was a major platform update. It introduced many new code classes for all aspects of developing an app from UI components like CardView, RecyclerView, Tabs, Buttons, Elevation, and, Navigation Drawer, that are still often used in Android app designs today. They are made compatible with newer platforms, by adding the dependency libararies. You will learn more about these as your complete the tutorials.Also introduced in Material Design were Graphics with Vectors, and Material Color Blends.
View Material Design Components
All these new Material Design code class components require a SDK target of at least 21, SDK compile version 21, and SDK build tools version of 21.0.0.
Coded as such on an android device with at least platform 5; your app should build and test without issue on this device that built it.
Targeting Platform Versions 21+
What if we want that same app to install on later versions, those greater than api 21. The app should also perform without issue.Now, lets suppose we want to install that same app on android version 4. which is api 20. As the app is now, (code wise), it might install, but the app cannot perform as intended because it does not have any code included to 'support the Material Design Components'.
For a specific Material Design component (example), lets use CardView.
CardView Support Libraries
In order to make our app with the 'CardView layout widget'; install and perform properly on android version 4, we are going to add some support libraries for CardView from Material Design.The support libraries as previously mentioned, are just a bunch of code packaged together and presented as a 'support library', for whatever code class it supports.
We, as a developer, choose the library we require for the code class we are including in our app.
In this case; our widget (CardView); we get the support library info(usually just a line of text with numbers at the end, see Example Code section for example dependency) and copy paste that into our build gradle at the dependency section.
Then we save the page; and the required library is downloaded from the web into our App Project.
Library Repositories
The code actually comes from a 'repository'; usually Maven, JCenter, Google-Maven. You can see these also: the repository names by default are already included in our app at the build script section of your app project build gradle which you can locate atApp Project Name / build gradle. The App Project / app / build gradle is the other build gradle where we set our SDKs and add dependencies. This one is known as 'app module level build gradle'. You can easily browse your app projects in AIDE to view and learn about these pages.
As mentioned, these default libraries are included for us in our template app we use to make our new apps. It is good to learn what they are and what they do.
Installing on Older Platforms
So, for our CardView; we have added the support library; and our SDKs stay as they were. We now Run and Build our app again.Now, our app can be installed on Android version 4 and will perform as it should.
You can now submit your app apk for publishing at app stores. In this scenario example; you would use Android Version 21(platform ver 5) as your target api; because that is the highest api version your app was tested on.
Android platform code classes are compatible with newer platforms but not usually with older ones. So for our CardView example; with a SDK target version of api 21; it will install and perform as it should on api 21, 22, 23, 24, 25 - 34(platform 14).
Ideally; for the current year, you would most likely use and test(or install your app) on newer platforms or for desktop use the Android Studio emulator for testing.
We used the Material Design CardView as our Example; so we used 21 as our SDK version target. You can set a higher api. You cannot set a lower SDK target than 21 when using the CardView widget.
Selecting and Adding Dependency Libraries
Libraries for code classes continue to evolve as new code classes are introduced and support for older android versions is ongoing.Android added with Material Design the appcompat support libraries. These are now a few years old but until recently were updated on a regular basis to include new codes or updates to improve existing ones.
Each new update of a support library like 'appcompat', gets a new update number, aka release number. These are usually incremented from the previous release and that number is included with the support text, usually a line of coding, which you add to the code at build gradle. The library code begins with the word implementation followed by the code itself: implementation 'androidx.cardview:cardview:1.0.0', and the last numbers are the version or release of the dependency.
This is the support library code for Material Design 'CardView', from the androidx support libraries.
implementation 'androidx.cardview:cardview:1.0.0'
This is the support library code for Material Design 'CardView', from appcompat support libraries.
compile 'com.android.support:cardview-v7:+'
Compile is no longer used, it is replaced with the world implementation for each dependency you add.
Android X Libraries
Androidx was introduced in android version 9, api 28. As of androidx, api 28, the appcompat libraries are no longer maintained. It is recommended now to use 'androidx' support libraries for new apps you develop. Androidx is api 28.
This means when you include code or libraries from 'androidx', you must use api 28 as your SDK target. If you use less than api 28, your app will not build; or app will not open.
Usually, you get error messages when you Run your app if your SDK target is not set correctly.
Additionally, because you are using 28 as the 'target SDK", you must also set your SDK 'compile version' to 28, and because your compile version is 28, you must set your 'SDK build tools version' to match your compile version;
Code them as:
SDK target version 28,
SDK compile version 28,
SDK build tools 28.0.3,
The build tools versions are at Android Developer website; as are Support Libraries and Api and Platform Releases.
Setting Min SDK
Your min SDK version can be 14 - 21. At Google, Target SDK Android 14 is recommended, that is API 34.This represents the older versions you want your app to be compatible with. For this, you want to determine how many devices are using a particular android version and is it a market you want for your app and its' features to target.
At this time, android APIs 14 and 16 have about a 5% share of android devices market.
You can easily research this information with 'android device distribution world'; or similar searches.
Also Read Handling Errors in AIDE
FYI - Links
CardView Support Library
Platforms with Api and Platform Features
Material Design Components
Android View
Android - popular widgets,components
Info - Support Libraries
Android x Api Packages
Android X
Summary
As an android app developer; you can use many different code classes. Some of these are from more recent android platforms; while others may be 'standard code classes' spanning all the platforms.
With every app you create the SDK min and target version api numbers must be included in the build gradle config and also the corresponding Compile version and Build tools version.
The template app we use to make our apps already have the SDK targets included, so most of the time these do not have to be changed. AIDE updates the release information so that the build process is on par with the most recent additions to Android platform. However, if you do want to change them it is easy to do, just replace the number showing with the number you want to use. This is done in the build gradle file of your app project.
Of particular importance for setting these is:
the api of the code class your including in the app code;(is it just standard code or specialty code requiring specific api and or libraries);
the min platform you want to target.
The best way to see the features and code classes of each platform is to read the api and platform page (link at FYI links). It provides platform and corresponding api number; as well as platform highlights.
This covers the 'basics' of coding the manifest and build gradle pages in your app project. To learn more about these pages follow the included links. As you learn to code with each tutorial, you will learn all about the pages and features mentioned in this first tutorial article.
Also Read Android Developer website Manifest File Features, Conventions, Libraries.... and;
Build Gradle - adding dependencies
Taste World Wines Flavours and Aromas
You May Like:
GOLF WITH LEFTIES, Golf Tips and Instruction Videos
This free script provided by
JavaScript
Kit
All Rights Reserved