That's an interesting idea: at each entry point, have a layer that delegates according to the SDK level.
My app has a reasonably complex architecture involving multiple entry-point activities (although only one launcher icon), a few services, a content provider and some widgets. Inter-app communication is also supported. There are indeed many ways around all this - and I think I like yours the most - but there are limitations to this: 1. Legacy users will keep on getting the updates even though those updates are only designed to affect later codebases. At best, it will be a pointless download for them. At worst, it will introduce a bug rendering the app useless. 2. You would still have to test the app on older SDK levels (because of point 1) 3. What about resources? I guess the res folder would have to have distinct copies for each SDK range 4. Permissions? A later version may require an additional permission which is not needed at all by the legacy code (and vice-versa). 5. IntentFilter & ContentProvider entries in the manifest. Those would have to expose entries for all sdk-ranges which could get messy. I like the thought of having an APK which I know works on SDK level 3&4 etc. I know that it will work for years to come because it hasn't been changed. There is a lot of reassurance in that. As an app becomes more and more complex, the potential for introducing a bug increases and so it makes sense to keep the APK a simple as possible. On 3 March 2011 19:55, Streets Of Boston <flyingdutc...@gmail.com> wrote: > I don't know how your app declares your activities, if they are public to > be used by any other component/app installed on the phone. > Let's assume your activities are all private, then there is a way to > deliver 2 apps in one APK. You could do this by creating two separate > code-paths for the 2 types of apps. > > > Set you min-sdk-version to the minimum (e,g 4 for 1.6) and > target-sdk-version for 11 (Honeycomb). > > Create a brand new 'Launcher' activity (you can make this one invisible). > This activity will examine what the OS version is and it will start up the > old root-activity of your app for 1.6 phones or start up a new activity > tailored to Honeycomb for 3.0 devives. > > You can either write brand-new code for every new activity for 3.0 devices, > keeping it entirely separate (e.g. a sub-package) from your original 1.6 > code. > If you decide to re-use code (utilities, data-object, even fragments (see > posts by Dianna that talks about providing a Fragment library for pre 3.0 > devices)), make absolutely sure that this code won't blow up on 1.6 devices. > > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
