Disadvantages of using Android Compatibility Library on Honeycomb [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I would like to know your opinion on disadvantages of using ACL on Honeycomb devices.

I think of using the Library for my application exclusively - even when it runs on Honeycomb itself - otherwise I would have to create 2 versions of mostly identical classes.

Primarily I am 开发者_如何学Gointerested in functionality (bugs) of Compatibility Library, its performance and memory usage vs native Honeycomb SDK. So if you have experience with creating separate classes both for ACL and for Honeycomb, let me know if results were worth the efforts - should I create duplicate classes or go with ACL-only.

As always, thanks for your support :)

---

If you plan to have one binary for both tablets and handsets, your fragments should all extend from the ACL -- otherwise you'll be building two apps. The benefit of the ACL is that you can build your app once (by extending its compatibility classes) and then run those fragments on all API levels >= 4.

The biggest drawback we encountered were ACL bugs related to animations and the back button on Honeycomb -- but these were [mostly] fixed with the support package r4. I don't recall any other issues (if there were any they were small enough that I don't remember them now).