Android Question Error Downgrading SDK

Marcos Alves

Well-Known Member
Licensed User
Longtime User
Hello,

we are already testing SDK 28 but, as recommended by @Erel , maintaining the use of SDK 26 in our production environment. But when we tried to change the path and target sdk level back to 26 (in apps already compiled with 28), we got the follow error while compiling:

B4X:
B4A Version: 8.30
Parsing code.    (0.40s)
Compiling code.    (1.51s)
Compiling layouts code.    (0.20s)
Organizing libraries.    (2.39s)
Generating R file.    Error
ERROR: In <declare-styleable> FontFamilyFont, unable to find attribute android:fontVariationSettings
ERROR: In <declare-styleable> FontFamilyFont, unable to find attribute android:ttcIndex

It looks that there is something that avoids downgrading SDK ... the error persists even after "clean project". If we change the target SDK and path to 28 again, the app is compiled without errors...

Any suggestion?
 

Marcos Alves

Well-Known Member
Licensed User
Longtime User
You need to understand how it works.

1. CHANGE the path to android.jar BACK to Api 28. B4A NEED Api 28 Android.jar to COMPILE.
2. Change the targetSDK of your app to 26.
Hello @DonManfred ,

I changed Target SDK in Manifest using Manifest Editor to 26 AND the path to SDK 26 also, since the first try... the error remains. I done other test also: tried the same thing with SDK 27, and the error persists - the only way to compile was to change Manifest and PATH to SDK 28 again...

Any suggestion?
 
Upvote 0

Marcos Alves

Well-Known Member
Licensed User
Longtime User
i had this error too in the past.
The solution was and IS to USE Android.jar from api 28. Tools configure paths.

The error does not happen here in no one of my projects. Using TargetSDK 26. I never used 28.
Maybe the problem is your old B4A

Hello @DonManfred ,

our B4A is always the last stable version. Now is 8.30. I know that sometimes I do some basic mistakes, but on my 35 years of programming and 5 years in B4A I can assure for you that this situation isn't the case . We used 28 to anticipate possible incompatibility issues in some of our more complex apps, but I'm trying to maintain two development processes: production in Target 26 and Test & development in target 28. But when I tried to downgrade a machine where I already compiled using target 28 I got the error above.
I'll spend some time to record a video showing step by step what we are doing and post here: could be important if we can find out what is happening.

Thanks!
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
With Android, the API that you have installed can create applications of a lower API level. So installed API >= targetAPI is ok. Installed API < targetAPI is not ok. If you have target API 26 and installed API 28, the finished app will only use up to API 26 functionality. There is no need to downgraded the installed API. I currently have API level 27 installed, but have no issues creating target API 26 apps that use only 26 and below features. Heck, I've even created target API level 13 apps without any issues (and yes, the finished app could only use features of API level 13 and below). That's what @DonManfred is trying to tell you, that it is not necessary to match the installed API Android toolkit with the target API level (it just needs to be equal or higher than the target API level).
 
Upvote 0

Marcos Alves

Well-Known Member
Licensed User
Longtime User

Hello @OliverA ,

Thanks for explanation. What intrigues me is why since I compiled the app with the path of SDK 28 I can't anymore change the path to 26 or 27 (even changing target sdk to 26 or 27 in Manifest)? Where is the "hidden flag" that says that the app was already compiled with path of SDK 28, even after a Clean Project? After a clean the compilation should work, doesn't it?
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
I may be wrong here and someone else can chime in: Sometimes the higher API SDK brings updated features to a lower API that does not interfere with the performance of that lower API level, but enhances it. So I'm guessing that API 28 added something to you target API 26 app (in this case something font related?) that works with target 26, but was not part of the original 26 SDK, but also does not break anything at the API 26 level. 1) I hope that made sense. 2) I hope someone else can confirm/deny this.
 
Upvote 0

DonManfred

Expert
Licensed User
Longtime User
but on my 35 years of programming and 5 years in B4A I can assure for you that this situation isn't the case
Not true. Even my 30+ years of programming and 6 years B4A i still do make mistakes. But i´ve a fast learning curve (Selfeducating).
 
Upvote 0

Marcos Alves

Well-Known Member
Licensed User
Longtime User
As I wrote in your other thread, the terms are important. You should set targetSdkVersion to 26 and you should use android.jar from platform-28.

The difference between them is explained here: android.jar / targetSdkVersion / minSdkVersion

Thanks @Erel . One last question: If I compile once using android.jar from sdk 28 path, what happens with source code that avoids changing back to the android.jar of a lower sdk path?
 
Upvote 0

Erel

B4X founder
Staff member
Licensed User
Longtime User
If I compile once using android.jar from sdk 28 path, what happens with source code that avoids changing back to the android.jar of a lower sdk path?
It is not related to previous compilations. It is related to resources included in some of the libraries which depend during compilation on android.jar from platform-28.
 
Upvote 0
Cookies are required to use this site. You must accept them to continue using the site. Learn more…