Not sure if I understood correctly compiling with 1.6 I can run on a 1.5 HTC Magic ?
I tried to download the upgrade from the HTC website but when entered the serial number the website says that the upgrade is not applicable for my phone On 28 out, 15:25, Michael MacDonald <googlec...@antlersoft.com> wrote: > I don't think this is as hard as you think. You don't need to have > multiple versions of the application. > > If you want to support different resolutions, just change (or add) the > targetSdkVersion attribute in your Android manifest to 4 (which is1.6). If > you don't change the minSdkVersion, it will still be available > to users with older versions of Android. > > Things only get tricky if you want to use API's from later versions of > Android, while still retaining compatibility with previous versions. > Then you have to isolate the code that uses the new API in a class that > you reference only dynamically, so you can test if the new API is > available before trying to use the class. > > Beowolve wrote: > > Hi all, > > > I have a few scenarios where I guess I am not alone with. There is no > > easy solution but this has to be on top of the list I think... > > > 1. Suppose you have an application that is compiled with1.5and is > > working fine even if started on a1.6device. But you now want to > > support other resolutions, so you need to compile with1.6. > > Problem: > > If I recompile and publish the new apk, the1.5users want see my > > applications. Users already downloaded my application can not > > upgrade... (will there be a "new version" available shown to them in > > the market?) > > > 2. Lets say your application works fine on1.5and1.6and you decided > > to publish your application twice with different package names. > > "MyApplication1.5" and "MyApplication1.6" for example. > > Problem: > > The user upgrading from a older version does not know that there is a > > new version, because you published a new Application. You can write it > > into the description and tell the user to download the1.6version but > > many users might not read that... > > Settings from the other application are lost... > > Your downloads are split into two applications, so you might not make > > it into the top ranks that easy . You might even need to publish 4 > > applications if you have a light and a paid version. > > > 3. Now 2.0 SDK is available and you want to add multi touch features > > or any other new stuff for all 2.0 users. > > Problem: > > The above problems are getting even worse. There is no way to easily > > upload multiple apks for the same application. > > Having to rename the package is also not making this better. Every > > time svn freaks out and marks everything as new. Sharing code between > > versions is difficult because of that. > > > I don't know if its just "3" (provider in Austria), but I still have > > not received an official update to1.6. Testing on the real device is > > not possible with a1.6image if you don't want to root your phone and > > update the rom manually. 2.0 will be on some devices soon, so there is > > definitely a need to support all 3 versions. > > > Conclusion: > > There should be a faster update cycle for the users or a slower update > > of new versions meaning bigger steps. > > or > > We get an easier way to support multiple versions. This also means we > > need a way to know how many actual devices with version1.5/1.6/ > > 2.0 are already sold and/or upgraded. If i know that1.5is only on > > about 5% of the devices left, then I can just stop supporting that > > version and upgrade. > > > At the moment we can just guess... -- 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
