开发者

Building/compilation with higher level SDK

开发者 https://www.devze.com 2023-04-11 04:49 出处:网络
I\'m a bit confused with one thing, look: Let\'s say we have source tree with <uses-sdk android:minSdkVersion=\"4\" android:targetSdkVersion=\"10\"/> declared in manifest

I'm a bit confused with one thing, look:

  1. Let's say we have source tree with <uses-sdk android:minSdkVersion="4" android:targetSdkVersion="10"/> declared in manifest
  2. I'm compiling those sources with SDK level 3 (SDK3.apk)
  3. Then I'm building sources with SDK level 10 (SDK10.apk)

What will be the d开发者_运维问答ifference between these 2 APK's? (SDK3.apk and SDK10.apk) I mean I'm asking not about technical details which libraries will use those APK, I'm asking about APK's behaviour on different devices with different OS'. And which one is better to use?

Update My project contains nothing special: make use of SQLite, screen off and SD dismount broadcast interception, usage of some telephony functions. Everything is within SDK level 3 functions/methods. I have both tested with SDK3.APK and SDK10.APK on different devices (older and brand new ones) - looks like workable, but still there's question.


Given the information you have provided, without regard to the UI classes, licensing (if any), and Layout classes, the following information can be provided.

SQLite received a number of small optimizations but nothing major. In particular, all of the previous functionality was kept intact and none of the general behaviors changed.

Telephony changed considerably. There is no argument that Telephony is more responsive the further we move forward in Android. From a Telephony standpoint, API 10 is much better. The reason for this was that many apps were unintentionally inhibiting incoming and outgoing calls. With the API 10, it is harder to do this unintentionally and apps generally receive better, more accurate information about calls in a more efficient manner. (And no, it is not simply due to processor and memory upgrades).

SD instructions became less restrictive as time progressed, and while writes and reads became easier, they also seemed to be slightly more faulty (depending on the phone). However, as long as you followed the guidelines, you should be fine. The Android documentation is pretty good about telling you how you should handle your data.

Now, for the stuff they don't tell you The general opinion is that as the APIs have increased, fewer hacks are needed to make your apps consistent across multiple phones. This is actually not the case. It is simply the knowledge about proper use of the platform propagating amongst its community members. For instance, it is possible to have a hack-less solution for something as "complicated" as a Home Screen, if you know how.

As you bridge more APIs with your code, complications are more common, creating a false need for hacks. This has been true on every piece of software on every platform since specific platform development began. (As an example, people are still complaining about support for IE6) Choosing a good point to start is the best practice and indeed program the way Google advises, with some notes.

Google obviously has not thought of all the cool things we can do. Otherwise, they wouldn't need us to make the platform the coolest one out there (IMHO). However, they do tell you how to appropriately use their Classes and Interfaces. Follow those guidelines and do your neat stuff "in between" them and your apps will perform well, no matter which API you use.

Some Other Stuff Some of the Activity and View behaviors are significantly improved in API 10, but most of this is in regard to event handling itself, rather than infrastructure. The benefits to using API 10 here are not solidified unless you are handling specific events or binding to data in particular ways.


In Reponse to Your Comment "Why is there no clear answer?" The reason why it always depends on the project and your usage is the same reason it has always been. OOP allows you to override and reprogram just about any aspect of any platform you are working with. Furthermore you can create your own implementations of things quite easily. Your imagination and innovation are the key here.

Ever used two pieces of software that have done exactly the same thing and thought "This one is the better of the two?" You have just experienced what I have described. It may be better because you are more familiar with its standards. However, it may also be better because it breaks those conventions in a more intuitive way.

The same thing can exhibit itself when a piece of software you like works on one device/computer, but not an another for no explicable reason. The key to a great piece of software is your insight to the solution, no matter which devices it works on. The key to a successful piece of software (from a customer's perspective) is how consistent the experience is. In other words, how many devices it works on and how many people it works for. I, personally, opt for somewhere in between, even though I love super-shiny solutions. Just because I think a solution is shiny, doesn't mean that my customers may all use my solution and I have to support as many as I can.

In Response to: "How is it related to minSDKLevel? Since the choice of which Android OS levels you are going to support is yours, the answer should be obvious. You are saying that your app can be installed on API 4 all the way through API 10 and you will support ALL of them. This means that your default result APK will have a solution for all of them (if you program it).

If, however, you build for specific versions (like many do with different APKs), then each has its own issues and own support. They may even (in fact, must in many case) have their own market entry. BUT, you SHOULD adjust your manifest for each individual build, if you choose this model so that an API 4 device does not see the API 10 APK, if you have an API 4 specific APK.


Conclusion In conclusion, what you can expect largely depends on how well you adhere to Google's guidelines for programming in Android and how inventive you are about bending the rules, but not breaking them. In general, most can expect a more consistent experience in API 10 than in API 3. With that experience is often a smoother response with an equivalently robust data engine. Your UI look and feel depends heavily upon the settings for each Layout and View, and can radically change between devices especially if you are creating all of your View dynamically. API 3 is definitely the more consistent of the two when it comes to handling UI, as API 10 has quite a few more options. I think most people would agree that API 10 is probably going to be a more satisfactory experience for your users as a whole.

FuzzicalLogic

P.S. As a note, I develop in API 7 as it has the widest range of supported devices, with a comparable set of options. Anything that is not implemented in 7 but is in 10, I can ultimately override to mimic. This is, however, my preference.


The difference is the android.jar which is shiped when your apk file is generated. When you building source with sdk level 4 then android.jar for sdk level 4 is used to build your apk file same is the case with sdk level 10.


Sdk level 10 can not be installed on device having api level lower than 10. sdk level 4 can not be installed on device having api level lower than 4. Both apk will behave in same manner on different device having different api levels unless and untill you have not used any deprecated stuff. For example if method m1 is deprecated after sdk level 5 and you are still using it in sdk level 10 then app will behavior is undefined when execution comes to call of method m1.

0

精彩评论

暂无评论...
验证码 换一张
取 消