Using --compileSdk for compile code for Android 4.2.2


#1

I’m trying to compile a simple code based on the dependencies presented in the package.json file below. However I need this code to be compiled to run on phones with Android API 17 (4.2.2) and I’m not succeeding.

{
  "name": "mobiletest_mobile_client_app",
  "version": "0.0.002",
  "description": "Interface no celular do Mobiletest para Clientes",
  "repository": {
    "type": "git",
    "url": "https://github.com/Mobiletest/MobileClientAPP"
  },
  "bugs": "https://github.com/Mobiletest/MobileClientAPP/issues",
  "keywords": [
    "test"
  ],
  "license": "SEE LICENSE IN LICENSE.md",
  "readme": "NativeScript Application for create a Mobile APP with manager test records",
  "homepage": "http://mogiletest.github.com/mobile_client_app",
  "author": "Carlos Delfino <consultoria@carlosdelfino.eti.br>",
  "nativescript": {
    "id": "br.com.ritech.Mobiletest.mobile.client.app",
    "tns-android": {
      "version": "2.3.0"
    },
    "tns-ios": {
      "version": "2.3.0"
    }
  },
  "dependencies": {
    "email-validator": "^1.0.7",
    "everlive-sdk": "^1.9.1",
    "font-awesome": "^4.7.0",
    "nativescript-orientation": "^1.5.4",
    "nativescript-platform-css": "^1.4.0",
    "nativescript-sqlite": "^1.1.2",
    "nativescript-statusbar": "^1.0.0",
    "nativescript-telerik-ui": "1.4.1",
    "tns-core-modules": "^2.4.4"
  },
  "main": "app.js", 
  "devDependencies": {
    "angular-ide": "^0.9.10",
    "babel-traverse": "6.22.1",
    "babel-types": "6.22.0",
    "babylon": "6.15.0",
    "lazy": "1.0.11"
  }
}

First I used the default, the application compiles but does not run on the emule or on the cell with API 4.2.2.

Then I tried to tune the version of tns-android to 2.3.0 and again I had the same problem

Then I tried to use the directive --compileSdk 17, but it complains that I need to have on my system installed at least version 22, this left me confused, I need version 22 on the desktop or the mobile, if on the phone so I can not use - -compileSdk 17, do I have to use 22?

I’ve been trying to find something relative for about three days, but all the postings they deal with - compileSdk seem to deal with another problem and do not go into too much detail.


#2

Well, I ended up finding a post in stackoverflow now: http://stackoverflow.com/questions/40583905/nativescript-android-api-version-check k which suggests reading the article: https://medium.com/google-developers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd#.pk6vs9nex which I’m reading now.

Other suggestions are welcome. I posted information soon about what I got


#3

I believe it’s somewhere on the docs site - at the time of writing this post you can’t use compileSdk lower than 22.

As you might have already read in other articles, compileSdk of say, 22, does not mean that the application will not work on a device of API level 17. What compileSdk does is limit the available Android API to the value you set. So, for example, if you compile with 22, you will not be able to access methods and classes introduced in 23 and up.

Now, if you are concerned about using platform API that may not be available in lower API levels like 17, 18, 19, you could manually check the version code of the executing device and act accordingly.

Having said all that, normally you don’t have to do any compatibility checking whatsoever if you don’t directly access the Android API.

EDIT: I guess I just answered a post where you also linked a response of mine… I should click the links more often :smiley:


#4

I’m learning, now I understand the function of --compileSdk better.

Everything indicates until now that I am using something that is not compatible with API 17, but I have not been able to find what it is yet, is there any way to facilitate such a search, or will I have to see each extension to find out what would be incompatible with API 17

Grateful.


#5

Usually the exception/logcat will show where the problem lies.


#6

I ended up discovering the problem, rebuilding the project from scratch and everything indicates that the problem was in the very large id, and in an image that was incorrect for the density of the device.

Now it’s okay.
Thanks.