The new version of SDK for Qt 5.12 doesn't include SDK Manager in the Tool folder, hence I needed Android Studio to Add/Remove the packages.
I know that APIs must be chosen based on the target and purposes. But since the APIs are new (28) and there are different options to download, it's rather puzzling what to download.
I don't have a real Android device nor want I use the Emulator. I merely wish to Build the program using Android kits and create APK files from them. Afterwards I will test those APK files on real Android devices which include new or middle aged smartphones and tablets.
For these purposes what packages should I install, for instance, what check boxes are needed to be checked here in the screenshot below. I will repeat the pattern for a number of lower APIs then.
If you don't want an emulator, then you don't want the "system images".
As for the API level, it really depends on what is the minimum API you want to target. If you download only the latest API, you significantly limit your targets, as the app will only run on the latest and greatest version of Android.
The safe lower limit seems to be API level 19, which is android 4.4. So you can use that to build your apps, and they will run on any version onward.
Additionally, if you want to publish to the market, you will have to set your target API to some of the latest versions, because google won't accept any older. Note that the "target SDK" is different from the "minimum required SDK", which you can still have at version 19.
There isn't much point in installing the latest SDK versions, as Qt isn't really using their features, I mean unless you are doing some Java native android app development.
The documentation for Qt 5.12 says "API 21", but 19 seems to work just fine, and it allows to target older devices that are stuck without OS updates - currently around 7-8% of active devices. Still, if you don't care about that, you should go with the recommended API version 21.
Related
I am using Delphi 10.4 (but my question is general enough to be relevant to any development environment - including ADS Jetpack Compose, React Native, etc.) which comes with installed Android SDK 29/NDK 21. From the one side, there is no way to ask Delphi 10.4 to use higher SDK (Trying to install Android SDK 31 and NDK 25 for Delphi 10.4 - what to provide in Delphi SDK manager wizards? is the description of my unsuccessful attempt). From the other side Google Play required all apps to target SDK 31 as of 2022.12.
So, I have the option (and some Delphi developers are constantly suggesting it) to manually edit AndroidManifest.xml and false state that app targets API 31 and at the same time I can continue compile it with SDK 29. My question is - can I falsely state higher target SDK API level and what could go wrong if I do this?
I did research what target SDK means exactly and https://proandroiddev.com/compilesdkversion-and-targetsdkversion-what-is-the-difference-b4227c663ba8 is the very fine explanation. Let me extract, summarize and adapt this article here.
So - there are 2 kind of features of Android apps. One kind of features target specific Android API versions. That means: if my app has min-SDK and target-SDK settings, then compilation includes all the SDK-specific implementations of this feature starting from the min-SDK and up to target-SDK. If compile-SDK < target-SDK (which is not advised, compile-SDK > target-SDK is advised), then the final apk includes the implementations for the interval [min-SDK, compile-SDK] only, compiler have no knwoledge about implementations (compile-SDK, target-SDK]. During the execution time the device OS determine the actual SDK of the device and the device OS can extract form the APK those version of the feature, that is the most closest to the actual device SDK.
Another kind of features have no such SDK-dependent implementations.
So - essentially. If I have the following values:
min-SDK: 23
compile-SDK: 29
target-SDK: 31
Then there can be feature X which have SDK-dependent implementations v23, v24, ..., v29, v30, v31. And compile-SDK-29 can compile only v23-v29 implementations in the final APK.
So - my question essentially boils down to the question how Android OS will handle the APK that states target-SDK=31, but which has implementations v23-v29 only?
I can imagine that Android OS has consistent protocol (all the targeted features) how to handle such situation and there can be 2 options only (assuming that actual device SDK is 30 or 31):
Android OS tries to read v30/v31 implementation of the feature and if it can not find the v30/v31 implementation of the feature then Android OS immediately reports the error about unsupported feature.
Android OS tries to read v30/v31 implementation of the feature and if it can not find the v30/v31 implementation of the feature then Android OS tries to read v29, v28, ..., min-SDK implementation of the feature and, of course, it finds some older implementation version and uses it. Android OS can report warning in logcat, uses sees the outdated behavior, of course, but otherwise the app is working and there is no any error message of interruption.
So, which scenario is true? I guess that 2nd scenario is true, because I have never seen any incompatibility messages during runtime, if app installs on the phone or tablet, then it certainly runs.
I can not find the reference, but it seems to me that I have seen one article which stated that there are well maintained code bases that uses compile-SDK < target-SDK, if the app vendor consciously decides to continue to use the behavior and functionality of the features as implemented for the previous SDK API versions. And such vendors set higher target-SDK just to get their apps accepted in Google Play.
, if app installs on the phone or tablet, then it certainly runs.
that's very not true. I have several cases where I have apps compiling with 32bit libs causing the app to instantly crash unless I specifically tell adb to install the app as 64bit.
What I assume is that it might not even compile if you have target SDK higher than compile SDK but even if it does compile, I think the app will simply crash on devices that runs SDK which has no definitions for the required functions. That's why when you write code you can check the SDK running on the device and apply the needed functions / functionality required for that SDK and if you fail to do that the app will crash. As in, say you have minSDK - 10 and targetSDK 30. If I'll run a function that has API X for SDK 10~20 but that API was changed to API Y from SDK 20~30 the app will compile and will be installed on all the devices. If I'll use API X only (that is, only for SDK 10~20) on a SDK 25 device, the app will simply crash when it will try to use that function.
so I'm using QT to develop an app for Android, and according to Sophos Mobile Security this app is "Built for outdated Android versions: this app doesn't support recent android security features. the app was built for an older version of android"
in qt creator I have android-25 set as the android build sdk (which I wouldn't consider old after all, it's 7.1.1 nougat)
how can I make this warning go away? Is there a way to build my app for a newer version of android without excluding users from using it? (I have 7.1.1, and at least I want to use my app)
thank you for your response in advance.
EDIT:
seems like there are (at least?) 3 spots where I can set an SDK version:
minimum required sdk, as seen on the screenshot here: Qt for android: change the application icon
target SDK version, as seen on the screenshot above
this was the only one I was aware an hour ago: projects->build->build android apk->android build sdk
what they govern, how to set them? should they be the same or different?
Android suggests you use the latest sdk version for targetSdkVersion and for build-tools version (they have to match). In fact, Google Play now requires you to target at least SDK 26. This will not prevent older devices from running app. Actually it will be more problematic for newer devices, as you are stating that app has been fully tested and can run on newer devices, and does not need backward compatibility. See https://developer.android.com/distribute/best-practices/develop/target-sdk for more details.
As for minSdkVersion, that is what will determine the earliest devices supported, and you should try to keep it as low as you can, and as 95-99% of your users.
I use minimum sdk version 1.6 and run app on android device 4.0 but the app layout look likes devices with android 1.6. Is not it possible to use proper sdk based on device android version?
For clear my mean, suppose:
I use min sdk version 1.6 and target 8.0. I want when it runs on device version 4 it uses sdk 4, on device version 5 it uses sdk 5 and so on.
You can support different API levels creating multiple APKs taking advantage of this Google Play feature.
It’s essential to adopt some good practices from the get-go and prevent unnecessary headaches further into the development process.
Creating Multiple APKs for Different API Levels explains these steps in detail.
In what scenarios would the Target SDK version and Build SDK version ("Compile with" in screen below) differ?
I'm trying to figure out why Target SDK wouldn't be used for both providing the API level the application is designed to run on, as well as compiling against the same SDK.
In what scenarios would the Target SDK version and Build SDK version ("Compile with" in screen below) differ?
When the developer sets them to be different values.
I'm trying to figure out why Target SDK wouldn't be used for both providing the API level the application is designed to run on, as well as compiling against the same SDK.
At the point in time when you create a new project, setting the build SDK and the target SDK to be the same is reasonably common, which is why that's the default in the new-project wizards.
However, developers may well want to raise the build SDK to a newer API level, while leaving the target SDK alone. The target SDK version controls some elements of forwards compatibility and therefore may change things that the developer is not ready to address just yet.
For example, suppose a developer created an app in mid-2013, and at that time set both the build SDK and the target SDK to be 18. Then, early this year, the developer started poking around with Android 4.4 (API Level 19). The developer wanted to add printing capability to her app. The simplest way to support API Level 19 printing is to set the build SDK to 19, so she could reference the relevant classes directly. However, KitKat also changed the behavior of classic AlarmManager methods like set() and setRepeating(), and she decides that she's not ready to deal with that just yet. Since those changes are tied to the target SDK version, she leaves her target SDK version on 18 for the time being, making a note to work on supporting the new inexact nature of AlarmManager alarms in the future. Hence, at this point, her build SDK is 19 and her target SDK is 18.
Target SDK: Highest API level that the application have been tested. The application should be compatible with all the devices with this API level or more recent API.
Compile with: API level with the application have been compiled. For default it's the highest possible level (now it should be Android 4.4.4 kit kat)
I would like to test and distribute my phonegap app. It already runs for iPhone.
At first I installed the newest SDK (4.0.3) but this one does not run on my phone. So... i guess I have to install more.
What do I need to install in the Android SDK Manager?
All SDKs? Do I need the Sample/Arm/GoogleAPI/Sources too?
Generally I install all the SDK versions as it is good to be able to test on the various emulators to make sure you app works in all versions of Android. You should always build your application with the latest SDK but in your AndroidManifest.xml file you should have a android:minSdkVersion set to the lowest Android level you want your app to run on. For now I recommend 7 (Android 2.1) as 97% of the phones are running 2.1 or above.
As you can see in the platform versions chart here it is recommended to use Android 2.1 or 2.2 SDK to cover almost all the Android devices on the market.
I think you don't need Sample/ARM/Sources, though if you need to use Google proprietary API (for example Google Maps API) you need to use Google API versions of 2.1 or 2.2.
You only need the SDK that matches the API level you intend to build for.
This page: http://developer.android.com/resources/dashboard/platform-versions.html
has a breakdown of what devices are most active in currrent use (accessed market within 2 weeks)
Judging by that, if you target 2.1 you'd be able to install your app on 98.3% of all such devices.
It is generally best to pick the oldest platform that supports all of the features you need. Just stay at or above 1.6, that is when support for multiple screen sizes was introduced.
As I think, the best solution is SDK 2.2. Many devices work with this android version.
On your Android phone go to settings->About Phone and view the Android version. This should be the sdk you will need. Afterwords, you can just change the target android sdk version in your app and it should run on your phone. As for the folders you speak of - they contain some examples, the source code of the sdk and some additional apis to use google services. It is up to you whether you will need them. You will definitely need the platform-tools from the Android SDK manager - they provide you with the adb tool that enables you to upload applications to your device.