Trying to sort out the topic. Here is how I found, I see (correct, if something is not understood / read). I will show and ask questions based on my application.

  1. minSdkVersion = 14 . The created application will work on API> = 14. Even on the latest androids. Exhibited when creating a project and it is advisable to set the most minimal API, because more coverage of devices.

  2. compileSdkVersion = 26 . The version of the API with which the application is compiled. Those. Once it costs 26 and it works, then on versions below it will also work 100%. So our application will work in the range from 14 to 26 API

  3. targetSdkVersion = 26 . It's like a review that I tested this application on API 26 and it works correctly. Does not carry any functionality in itself.

Questions:

  1. I understood everything correctly?

  2. Why compileSdkVersion and targetSdkVersion exhibited 26, if I have downloaded API 27, 28? is it worth to change the values ​​in build.gradle from 26 to 27/28?

  3. After a while, the phone comes out with API 30. Will the application work on it?

  4. Where to see the width of the application x32 / x64? what does it even affect?

I do not understand all these subtleties. All that adequate found and understood - wrote. the rest is a dark forest.

  • one
    No. 3 - Yes, No. 4 - digit capacity is important only for native libraries, bytecode does not have such a parameter. - Eugene Krivenja

3 answers 3

minSdkVersion is the minimum version of the API on which your program can run. This parameter not only expands the reach of devices, but also obliges you to use the capabilities of only this (and previously released) API. By specifying this parameter = 1, you will be forced to write your code, as if the android just came out and there were no 27 updates to api, including all those new classes and methods that appeared during these 27 updates - this is a sophisticated mockery of yourself and practice available units.
However, any developer would like to "cover" as many devices as possible and use all the features of the latest api. Support libraries come to the rescue here, which connect as a separate module and duplicate some of the capabilities of new api, so that the developer can use them in earlier versions. There are quite a few such libraries (see the link) and each one solves a specific task (for example, AppCompat allows you to use the Material interface on API below 21).
On the current day, the support libraries themselves have a minimum version limit of up to api 14 (which corresponds to android 4.0), so for the largest and relatively painless coverage of devices the minSDKversion value can be set to 14 (we lose 0.2% of devices , which is quite a reasonable fee) . In practice, this value can be increased to 16 (android 4.1) without significant losses.
ps: at the current time, the support libraries are migrated to the androidX and JetPack packages, this should be taken into account later.

targetSDKversion indicates "compatibility" with a specific api. This parameter has such an effect that specifying it, for example = 1, you get the interface (type of widgets) of the first android, even if you run such an application on the latest version or specifying a value less than 23, your program will not request runtime permision, on devices with api is more than 23 (will work in emulation mode of such permissions). Part of the effect is that the program will assume that it is executed in the api parameter specified by this parameter, even if there is another api on the real device (but there are nuances here, as always). It is recommended to indicate the parameter by the latest release api (today it is 28) in order to avoid difficulties, incomprehensible behavior and the very nuances.

compileSDKversion indicates with which api your program will be compiled (from which api to compile the code). By specifying this parameter, for example, equal to 23, the classes and methods of later api will be unavailable (however, they will still be unavailable due to the minSDKversion constraint). This parameter is also recommended to indicate the latest release version of api (today it is 28). There is also such a connection that the major version of the support library cannot be greater than the value of compileSDKversion (if you want to use libraries of version 28.xx, then this parameter cannot be less than 28)

By specifying these three parameters in some digits, your application will run on all devices, from the one specified in minSDKversion to the current, that is, specifying compileSDKversion = 26 your application will work on api 30 when it comes out (you can only restrict maxSDKversion parameter, but it is usually not specified at all)

The digit capacity of the processor in the "classic" android application is not taken into account from the word at all. This parameter will be relevant when you decide to use native C / C ++ code in your application and will need to be defined with plug-in C compilers (it has its own for each processor architecture)

  • "will be unavailable due to minSDKversion restriction" - only here I do not agree. Example: minSdkVersion = 14, calmly calling the new FingerprintDialog on Android 9, if you set the other two parameters correctly. - Eugene Krivenja
  • @EugeneKrivenja I don’t think that what you are writing about is possible (calling classes / methods that are added after the specified minimum api) without additional annotations in the code, like @RequiresApi or there @TargetApi or other checks in the code itself, only indicating "the other two parameters ", otherwise there would be no need to specify the minimum api ... - pavlofff
  • Perhaps annotations are used to mark the code, but it is possible without them. Once there were no these annotations and everything worked through 'if (Build.VERSION.SDK_INT> = ...)' - Eugene Krivenja

1) minSdkVersion = 14 - It is true that it will work from version 14 and higher, but it is impractical to set the minimum API, since android versions 2.x.x less than 1%. Using API version 14, you lose the features available in version 4.x. IMPORTANT! It all depends on the specific software requirements. The lower the API version, the harder it is to develop and support. Android version history .

For questions:

3) The new APIs support the old Java, and if I correctly understood Android adhere to backward compatibility.

4) Where does the need for such information come from? Is the OS bit or does the application support 64 architectures? What I mean is that sometimes, when learning, it bears the wrong direction, and it can take a lot of time to study not very valuable information.

For other questions I will not answer, because I'm not sure that I can explain correctly and clearly.

PS My personal opinion. "Dark Forest" covered practice. Think up a project for yourself, set tasks (specific, not all possible features and technologies at once) and gradually learn how to implement the project. Dark places will become less.

    @pavlofff wrote true, but a lot :)
    I will try to enter a couple of sentences.

    minSdkVersion tells the compiler how to generate bytecode so that it runs on firmware with such a minimum API level; tells the compiler what errors and warnings should be shown so that the programmer does not stupidly call the API that is newer than the specified one; tells the device whether the application is compatible with its firmware.

    targetSDKversion tells the compiler what maximum API level is available (new ones are not available at all); tells the device in which "compatibility mode" the application to run (if it is higher, run as its own).

    compileSDKversion indicates which set of tools from the Android SDK to use. It is always recommended to use the latter.

    The rest is derived from these rules.

    Another important rule: minSdkVersion <= targetSDKversion <= compileSDKversion