Linked by Thom Holwerda on Fri 1st Feb 2013 18:25 UTC
Thread beginning with comment 551235
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
In which case the developer made the decision not to support API-level <14 cause eg the app/widget/service needs features that are only available in >13. Point is that decision is up to the dev. If the dev likes to support <14 then there is no reason to not AND all newer versions are supported out of the box.
Edited 2013-02-03 13:03 UTC
RE[6]: Comment by Nelson
by darknexus on Sun 3rd Feb 2013 23:32
in reply to "RE[5]: Comment by Nelson"
Nice theory, but it doesn't always work that way if either the API changes or an OEM does something odd to parts of their phone (Samsung, I'm looking at you). In these situations, an update is still needed. The app will only run on newer versions of the API so long as the API functions the app relies upon remain unchanged. You don't get support by default when changes occur.





Member since:
2012-09-21
Handling API fragmentation is much easier than platform fragmentation.
This is only a problem for the older (WP7) device. Just the same as an Android application that has a minimum API level of 14 is not going to run on a Gingerbread device.