4

I'm just wondering, if the latest Android SDK installed on a device contains code of all the previous versions as well?

So if I target API level 10 in my app and install it on a device with Lollipop, will it just take and use Gingerbread SDK exactly as it was 3 years ago?

Or is there just one codebase for all versions with a lot of checks and switches which is then run by some kind of compatibility mode picking the correct code and enabling methods of the version of SDK I target?

I read the article about android:targetSdkVersion specified in Manifest but still would like to know how this works internally.

Marcel Bro
  • 4,907
  • 4
  • 43
  • 70
  • 2
    No, but they are usually backward compatible down to the bugs. – user1095108 Nov 13 '14 at 10:39
  • @user1095108 Yeah, but how is the backward compatibility realized? You say the system doesn't contain the code of previous versions. So what happens when I use a method which is no longer available in the current SDK? Or what if code of the method changed? Where does the system get the original code? – Marcel Bro Nov 13 '14 at 13:19
  • SDK exposes interface for developer to use, and interfaces are backward compatible. – bladefury Nov 14 '14 at 08:00

2 Answers2

0

Ok, I just surfed a bit around on the source code (which you can find here: https://github.com/android/platform_frameworks_base). I'm not an engineer of the Android framework, I was just curious about your question and here is what I found.

It does not contain all the different versions of source code. You can imagine that this would result in a nightmare if more and more versions become available. Foremost, you would have different (buggy) versions of the same method without fixing them just to keep them the same.

In the source code, you can find places like these: (see https://github.com/android/platform_frameworks_base/blob/59701b9ba5c453e327bc0e6873a9f6ff87a10391/core/java/com/android/internal/view/ActionBarPolicy.java#L55)

public boolean hasEmbeddedTabs() {
    final int targetSdk = mContext.getApplicationInfo().targetSdkVersion;
    if (targetSdk >= Build.VERSION_CODES.JELLY_BEAN) {
        return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs);
    }

    // ...
    return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs_pre_jb);
}

So the Android developers do the version check in the code where necessary. But these checks are not as necessary as you think (I guess). What's the reason for changing a method?

  • method is buggy: All they need to do is fix the bug. Tests will make sure that the general behavior of the method keeps the same
  • method is deprecated: The guys can not remove the method, all they can do is mark it as deprecated and hope for the best. Compilers will do the rest.
  • method behavior has to change: Well, I guess that is something they can not do easily. They can work around with version codes (which is pretty ugly and becomes a maintenance nightmare), or they just introduce a new API. That's the reason why you'll find a lot of APIs just doing the same
akohout
  • 1,802
  • 3
  • 23
  • 42
-1

If you have write down a code with latest android sdk and install it in your device. It means actually you are using latest android.jar(you can see android.jar in your project) file while compiling/Executing code.

Now If you install your application in ginger bread device then android.jar(latest) has a backward compatibility(if required) to run code in Gingerbread device.and if you define target sdk version 10 and running app on Higher API level ,then it will run smooth except your compatibility behavior disable in respective device other than targeted devices.

Anand Phadke
  • 531
  • 3
  • 28