Well it's everybody's guess right now.
First, let me interject a remark regarding having to root a device for 1.6: Normally you shouldn't have to do that. See if you can find the installation packages for your device and upgrade manually. As far as the Google Ion is concerned, for instance, HTC offers the required packages and instructions on their web site. Other than that... I wouldn't worry about 2.0 that much quite yet. What I've done is to blank out Verizon in the Android Market. They are the only carrier that I'm aware of that's said to be pushing a 2.0 device sometime in the near future, and sure, that'll miss a 1.5 device they'll be coming out with. Although you might not reach every last potential customer when you do that.. you'll buy yourself some time so you can establish yourself comfortably on 1.6 and square that issue away first. You may find none or only small changes are required to accommodate 1.6 so that should cover 1.5 and 1.6 for you. Then you go on to new challenges. On Oct 28, 8:19 am, Beowolve <[email protected]> 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 with 1.5 and is > working fine even if started on a 1.6 device. But you now want to > support other resolutions, so you need to compile with 1.6. > Problem: > If I recompile and publish the new apk, the 1.5 users 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 on 1.5 and 1.6 and you decided > to publish your application twice with different package names. > "MyApplication 1.5" and "MyApplication 1.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 the 1.6 version 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 to 1.6. Testing on the real device is > not possible with a 1.6 image 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 version 1.5 / 1.6 / > 2.0 are already sold and/or upgraded. If i know that 1.5 is 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
