subject:"\[android\-developers\] Re\: ATTENTION ANDROID TEAM\: Take back control of Android."

Hmm, I've toyed with that a while back, and as far as I remember, the
app won't even launch, and crash with a class-not-found exception
(makes somewhat sense).
AFAIK, you cannot slide in dummy classes in Android's namespace work
around that either. Or did I miss something?

On Jan 18, 2:48 am, Christine christine.kar...@gmail.com wrote:
  As far as I have seen, you can
 have 2.1 classes in a 1.6 app, as long as you don't instantiate them.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 7:22 AM, JP joachim.pfeif...@gmail.com wrote:

 Hmm, I've toyed with that a while back, and as far as I remember, the
 app won't even launch, and crash with a class-not-found exception
 (makes somewhat sense).


If you just do things correctly, it is fine.  And correctly means: make sure
that the code that runs when on an older version of the will never reference
code that uses newer APIs.

An article on doing this is here;  note in particular the last part, about
how you can have classes that use new APIs and detect whether to use those
classes.  (You could also just check the platform version to decide whether
to use it.)

http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html

Also note that simple constants like integers get compiled in to your app
instead of referencing the original symbol, so you don't need to do anything
when using new constants like flags.  There are a lot of other things that
conveniently work out as well -- for example, here is sample code for a
Service that uses the new 2.0 APIs if available but still works on older
versions of the platform:

// This is the old onStart method that will be called on the pre-2.0
// platform.  On 2.0 or later we override onStartCommand() so this
// method will not be called.
@Override
public void onStart(Intent intent, int startId) {
handleStart(intent, startId);
}

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
handleStart(intent, startId);
return START_NOT_STICKY;
}

void handleStart(Intent intent, int startId) {
// do work
}


If there are specific issues people are having with using newer APIs in an a
compatible way, it would be really useful to post a question about them
(please in a separate thread) so that they can be addressed.  Hopefully in
most cases it is just a matter of knowing the tricks to do, though there may
be ways we have done some new APIs that make them needlessly more difficult
to use that we should avoid in the future.

Finally, as far as dealing with multiple versions of the platform -- how
different is this, really, than Windows and MacOS where there are three or
more different major versions of those platforms in active use?  (And on
MacOS, for quite a while now different CPU architectures!)  You just do on
Android exactly the same thing you do on those platforms: look at the
distribution of versions to decide the minimum one you want to target, and
do the appropriate thing for using newer APIs when you want to do that.

Honestly I get really frustrated when people talk about different versions
of the platform as fragmentation.  Where does that come from??  Is Windows
fragmented?  Is MacOS fragmented?  People talk about Android fragmentation
in these terms as if it is this unique, novel, killer issue in Android, and
yet it is little different than other platforms.

The main difference is, yes, a user of a particular phone can't go out and
buy a newer version of the platform in order to run your app.  Unfortunately
there isn't really a solution to this -- nobody but the hardware
manufacturer can supply newer versions of the platform to their device,
since they need to include the drivers and customization that are needed for
that device.  On the other hand, if you are doing your app on Windows, what
is the chance that they would upgrade from XP to Windows 7 just to buy and
run it?

(Then we can go off on web-based apps and the various browser versions that
need to be supported.)

But let's look at the current situation: the oldest version of the platform
that developers need to worry about is 1.5, which was finished less than a
year ago.  It appears to me that most of the manufacturers that have such
devices on the market have pledged to update them to 2.x.  If things proceed
how it sounds, I think the bulk of the devices will be running a platform
version released in the last year.  So that gives you an upper bound of
maybe 4 platform versions to support.  (And keep in mind -- doing 4
significant platform releases in a year is pretty extreme, and maybe not
something that will continue.  If you think it is hard on you, imagine the
poor platform developers. :p)

Now I wouldn't be surprised to see the active versions spread out over time,
as older devices are no longer supported so stay on an older version of the
platform.  But if we assume the active lifetime of a smartphone is around 2
years, there are going to be strong bounds on how old a version of the
platform you need to go down to, to support most active phones.

And even if 1.5 continues to ship on new phones for years and you need to
support it to get 80% of the market -- that platform release is a very rich
and functional base.  There are a few things that you'd need to do to work
well on newer platforms (supporting the new Contacts API probably being the
biggest), but for the most part you can just focus

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

2010-01-18 Thread Kevin Duffey

Good reply Dianne. I get pissed when I read blogs about how fragmented
Android is as well. I don't get how it's fragmented. The only fragmentation
that seems slightly just is the issue where individual phone vendors are
providing their own special UI and extra features. I think the biggest issue
that we may face is if our app doesn't work on those devices due to them
rebuilding android for their device that may affect our apps running on them
as they should. I personally don't know if this is happening. So far most
posts I've seen indicate the issue of phones that are 1.5 to 2.1 with 1.5
apps not working on 2.0 or vice versa.

Dianne, can you clarify the issue of updates... if I have a 1.5 app and
update my app, changing the minsdk to 2.1, will a user on a 1.5 phone be
able to update to the 2.1 version? One post here indicated that once a user
has installed the app, which was fine for the 1.5 app on a 1.5 phone... that
they can then get the updates even if the minsdk of the updated app is
higher than the phone it's to be run on? That doesn't make any sense that if
it's not installed, it wont even show up (which is good), but if you
installed it then update it to work on newer versions, that the older api
phones can still update to it, most likely causing it to not work any more.
It seems to me we're forced to build a new app for the later api IF it might
not work on the older api devices due to some api calls, such as the
contacts api.



On Mon, Jan 18, 2010 at 10:35 AM, Dianne Hackborn hack...@android.comwrote:

 On Mon, Jan 18, 2010 at 7:22 AM, JP joachim.pfeif...@gmail.com wrote:

 Hmm, I've toyed with that a while back, and as far as I remember, the
 app won't even launch, and crash with a class-not-found exception
 (makes somewhat sense).


 If you just do things correctly, it is fine.  And correctly means: make
 sure that the code that runs when on an older version of the will never
 reference code that uses newer APIs.

 An article on doing this is here;  note in particular the last part, about
 how you can have classes that use new APIs and detect whether to use those
 classes.  (You could also just check the platform version to decide whether
 to use it.)


 http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html

 Also note that simple constants like integers get compiled in to your app
 instead of referencing the original symbol, so you don't need to do anything
 when using new constants like flags.  There are a lot of other things that
 conveniently work out as well -- for example, here is sample code for a
 Service that uses the new 2.0 APIs if available but still works on older
 versions of the platform:

 // This is the old onStart method that will be called on the pre-2.0
 // platform.  On 2.0 or later we override onStartCommand() so this
 // method will not be called.
 @Override
 public void onStart(Intent intent, int startId) {
 handleStart(intent, startId);
 }

 @Override
 public int onStartCommand(Intent intent, int flags, int startId) {
 handleStart(intent, startId);
 return START_NOT_STICKY;
 }

 void handleStart(Intent intent, int startId) {
 // do work
 }


 If there are specific issues people are having with using newer APIs in an
 a compatible way, it would be really useful to post a question about them
 (please in a separate thread) so that they can be addressed.  Hopefully in
 most cases it is just a matter of knowing the tricks to do, though there may
 be ways we have done some new APIs that make them needlessly more difficult
 to use that we should avoid in the future.

 Finally, as far as dealing with multiple versions of the platform -- how
 different is this, really, than Windows and MacOS where there are three or
 more different major versions of those platforms in active use?  (And on
 MacOS, for quite a while now different CPU architectures!)  You just do on
 Android exactly the same thing you do on those platforms: look at the
 distribution of versions to decide the minimum one you want to target, and
 do the appropriate thing for using newer APIs when you want to do that.

 Honestly I get really frustrated when people talk about different versions
 of the platform as fragmentation.  Where does that come from??  Is Windows
 fragmented?  Is MacOS fragmented?  People talk about Android fragmentation
 in these terms as if it is this unique, novel, killer issue in Android, and
 yet it is little different than other platforms.

 The main difference is, yes, a user of a particular phone can't go out and
 buy a newer version of the platform in order to run your app.  Unfortunately
 there isn't really a solution to this -- nobody but the hardware
 manufacturer can supply newer versions of the platform to their device,
 since they need to include the drivers and customization that are needed for
 that device.  On the other hand, if you are doing your app on Windows, what

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.



On Jan 18, 10:35 am, Dianne Hackborn hack...@android.com wrote:
 On Mon, Jan 18, 2010 at 7:22 AM, JP joachim.pfeif...@gmail.com wrote:
  Hmm, I've toyed with that a while back, and as far as I remember, the
  app won't even launch, and crash with a class-not-found exception
  (makes somewhat sense).


 http://android-developers.blogspot.com/2009/04/backward-compatibility...

This means having to cut off users on older Android releases, no?
Kevin illustrates the problem nicely.
It's unfortunate that some of the carriers and manufacturers haven't
caught on to the idea of bringing their products along for the ride,
at least not yet, which I believe is one core issue of the barrage of
complaints.


 Finally, as far as dealing with multiple versions of the platform -- how
 different is this, really, than Windows and MacOS where there are three or
 more different major versions of those platforms in active use?  (And on
 MacOS, for quite a while now different CPU architectures!)  You just do on
 Android exactly the same thing you do on those platforms: look at the
 distribution of versions to decide the minimum one you want to target, and
 do the appropriate thing for using newer APIs when you want to do that.

It is different in that XP through Windows 7 have been released over
the course of, what, eight years now? Users are much more educated and
experienced in what to expect. At work, I, like many users
(hopefully), just pick up the phone or send an email, and the
problem will be taken care of.
On a mobile device however... it just kindof ought to work, which
isn't an unreasonable expectation. Being facetious with the backwards
logic, the level of support that Google set aside to support the
release of the N1 seems to confirm that idea.
As far as OS X goes, during a couple of years of transition, Apple
supported fat binaries just like they did when they switched
OpenSTEP from Motorola to Intel a decade earlier. There's experience
with that, and in the mobile environment, this is all new stuff and
needs to be managed accordingly, IMHO.
I want to add, no question of course, it would be unjust to criticize
anybody that an expectation wasn't set that Android would be subjected
to a degree of fragmentation when Android was first released
wayback. Yet, here we are, and it would be disappointing to see the
issue glossed over.


 But let's look at the current situation: the oldest version of the platform
 that developers need to worry about is 1.5, which was finished less than a
 year ago.  It appears to me that most of the manufacturers that have such
 devices on the market have pledged to update them to 2.x.  If things proceed
 how it sounds, I think the bulk of the devices will be running a platform
 version released in the last year.  So that gives you an upper bound of
 maybe 4 platform versions to support.  (And keep in mind -- doing 4
 significant platform releases in a year is pretty extreme, and maybe not
 something that will continue.  If you think it is hard on you, imagine the
 poor platform developers. :p)
Let's hope for the best then.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 1:58 PM, JP joachim.pfeif...@gmail.com wrote:
 It's unfortunate that some of the carriers and manufacturers haven't
 caught on to the idea of bringing their products along for the ride,

There's no incentive.  The (phone) sale has already been made, why on
earth would they then want to also support it?


-- 
Greg Donald
destiney.com | gregdonald.com
-- 
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

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.


Exactly. That's how they operate. Kindof enticing when you're a dev.
Crank it out, push it to the consumer, hope it runs and if there's
nothing major (like Rogers' 911 issue), leave the code behind and move
on to the next thing.

On Jan 18, 12:03 pm, Greg Donald gdon...@gmail.com wrote:
 On Mon, Jan 18, 2010 at 1:58 PM, JP joachim.pfeif...@gmail.com wrote:
  It's unfortunate that some of the carriers and manufacturers haven't
  caught on to the idea of bringing their products along for the ride,

 There's no incentive.  The (phone) sale has already been made, why on
 earth would they then want to also support it?

 --
 Greg Donald
 destiney.com | gregdonald.com
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 10:57 AM, Kevin Duffey andjar...@gmail.com wrote:

 Good reply Dianne. I get pissed when I read blogs about how fragmented
 Android is as well. I don't get how it's fragmented. The only fragmentation
 that seems slightly just is the issue where individual phone vendors are
 providing their own special UI and extra features. I think the biggest issue
 that we may face is if our app doesn't work on those devices due to them
 rebuilding android for their device that may affect our apps running on them
 as they should. I personally don't know if this is happening. So far most
 posts I've seen indicate the issue of phones that are 1.5 to 2.1 with 1.5
 apps not working on 2.0 or vice versa.


Yeah manufacturer customization is definitely the kind of fragmentation that
is more unusual to Android, and something we care a lot about.  There have
certainly been some issues there, but I think a lot of this is just everyone
learning how to do things (manufacturers, developers, and the platform) to
avoid the problems.  Certainly, it is not yet anywhere near like what MIDP
got like, which is the scary monster that people are conjuring up (whether
they realize it or not) when they say fragmentation.


 Dianne, can you clarify the issue of updates... if I have a 1.5 app and
 update my app, changing the minsdk to 2.1, will a user on a 1.5 phone be
 able to update to the 2.1 version? One post here indicated that once a user
 has installed the app, which was fine for the 1.5 app on a 1.5 phone... that
 they can then get the updates even if the minsdk of the updated app is
 higher than the phone it's to be run on? That doesn't make any sense that if
 it's not installed, it wont even show up (which is good), but if you
 installed it then update it to work on newer versions, that the older api
 phones can still update to it, most likely causing it to not work any more.
 It seems to me we're forced to build a new app for the later api IF it might
 not work on the older api devices due to some api calls, such as the
 contacts api.


I don't work on the Market team, so I'm  not sure of the current situation,
but if you say minSdkVerion=5 then your app should never be delivered to a
device running something  5.  If there are cases when it can be, then that
needs to be fixed.

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 12:14 PM, JP joachim.pfeif...@gmail.com wrote:

 Exactly. That's how they operate. Kindof enticing when you're a dev.
 Crank it out, push it to the consumer, hope it runs and if there's
 nothing major (like Rogers' 911 issue), leave the code behind and move
 on to the next thing.


Actually I am seeing a lot of positive change in this regard -- most of the
major manufacturers (HTC, Motorola) seem to have publicly stated that they
will be delivering a significant update to their current devices.

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 11:58 AM, JP joachim.pfeif...@gmail.com wrote:

  http://android-developers.blogspot.com/2009/04/backward-compatibility...
 This means having to cut off users on older Android releases, no?


Um.  No?  The entire article is about how to use newer APIs while remaining
compatible with older platforms.  Am I missing something?


 Kevin illustrates the problem nicely.


What is that exactly?  I see him talking about incompatible manufacturer
customizations and how fixing those are the responsibility of the
manufacturer (true), about newer platform versions being compatible with
older ones and maintaining support for older ones not being a big deal, and
concern about minSdkVersion not filtering app from older platforms which
should definitely not be true.

I'd just like to understand what the specific concern is.


 It is different in that XP through Windows 7 have been released over
 the course of, what, eight years now?


True, we have gone through a number of releases in the last year.  Of course
windows has also gone through lots of service packs etc.  But regardless, in
both cases basically one release builds on another, so you are looking at
targeting release X through Y and whatever number of intermediate steps
there are between is not that much of an issue (though you will certainly
want to be testing against intermediate release to verify there are no
surprises).


 Users are much more educated and
 experienced in what to expect. At work, I, like many users
 (hopefully), just pick up the phone or send an email, and the
 problem will be taken care of.
 On a mobile device however... it just kindof ought to work, which
 isn't an unreasonable expectation. Being facetious with the backwards
 logic, the level of support that Google set aside to support the
 release of the N1 seems to confirm that idea.


Sorry I am really not following this part. :}  Yes, you should be able to
just pick up a phone and use it, and for the most part that is the case (as
long as developers properly mark their minSdkVersion to not be visible on
older platforms, and the occasional manufacturer-specific bug here and
there).  I don't know how much support you think Google set aside for the N1
(was it large or small?  support for what?) so I am pretty lost there.


 As far as OS X goes, during a couple of years of transition, Apple
 supported fat binaries just like they did when they switched
 OpenSTEP from Motorola to Intel a decade earlier. There's experience
 with that, and in the mobile environment, this is all new stuff and
 needs to be managed accordingly, IMHO.


Sure and when 1.6 came out to introduce new screen support, it also included
a lot of compatibility design and code to ensure that existing applications
would work on the new screens.  (Or when not possible, such as QVGA screens,
require that applications be explicitly updated and marked as compatible
with them before allowing them to be available to users of those devices).

What's different here?


 I want to add, no question of course, it would be unjust to criticize
 anybody that an expectation wasn't set that Android would be subjected
 to a degree of fragmentation when Android was first released
 wayback. Yet, here we are, and it would be disappointing to see the
 issue glossed over.


I'm not sure how things are being glossed over...?

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.
-- 
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

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

2010-01-18 Thread Alberto

Exactly, some carriers won't go through the trouble of doing OTA
updates, your Android experience would vary depending on what carrier
you're. Also when I talk about fragmentation, I'm not just talking
about apps compatibility, but also the user experience is very
different from 1.6 to 2.1, some people might hate or love Android
depending on what version they're using.

Dianne: I understand the issue with manufacturers and drivers, but
even if manufacturers have to prepare the updates for each handsets,
wouldn't be possible for Google to distribute those updates through
their own channels instead of going the carriers' way, for example,
correct me if I'm wrong in any of this:

1. Google releases the source code
2. Manufacturers customizes it for their handsets (drivers, etc)
3. They send it back to Google
4. Google updates most Android phones through their own channel at the
same time, very quickly most phones are running the latest version

I know this is oversimplifying it a lot, and in the real world it
doesn't work like this, but I think I'm onto something, if the updates
are left to the carriers some phones will get the updates and others
won't, maybe that's something you guys can live with.

With all that said, even if there's nothing Google can do about the
updates, a companion desktop application for Android would help keep
the platform together, kind of like the lowest common denominator that
every Google Experience phone can plug into.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 2:32 PM, Dianne Hackborn hack...@android.com wrote:
 Actually I am seeing a lot of positive change in this regard -- most of the
 major manufacturers (HTC, Motorola) seem to have publicly stated that they
 will be delivering a significant update to their current devices.

Public statements don't mean much to me personally.

A Google employee named Dontae publicly stated my Marketplace stats
would be fixed soon for example:

http://www.google.com/support/forum/p/Android+Market/thread?tid=4c5752ca3e5af4ffhl=en#all

Our team has implemented a fix that will return all impacted
developers' Active User numbers to normal.

Four weeks and 3 days later, nothing.

And after the hell me and a colleague went through proving to HTC they
had the icon crash bug some months back, please forgive me if I don't
believe an update is coming until I see it first hand.


-- 
Greg Donald
destiney.com | gregdonald.com
-- 
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

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

2010-01-18 Thread Christine

It's good to see Google staff take this issue seriously :-)

I'll repeat my personal opinion that fragmentation will not be so much
of an issue, unless you desperately need 2.x features in your app, in
which case you'll have to accept a 1% market share of your app.

On Jan 18, 9:45 pm, Dianne Hackborn hack...@android.com wrote:
 On Mon, Jan 18, 2010 at 11:58 AM, JP joachim.pfeif...@gmail.com wrote:
  http://android-developers.blogspot.com/2009/04/backward-compatibility...
  This means having to cut off users on older Android releases, no?

 Um.  No?  The entire article is about how to use newer APIs while remaining
 compatible with older platforms.  Am I missing something?

  Kevin illustrates the problem nicely.

 What is that exactly?  I see him talking about incompatible manufacturer
 customizations and how fixing those are the responsibility of the
 manufacturer (true), about newer platform versions being compatible with
 older ones and maintaining support for older ones not being a big deal, and
 concern about minSdkVersion not filtering app from older platforms which
 should definitely not be true.

 I'd just like to understand what the specific concern is.

  It is different in that XP through Windows 7 have been released over
  the course of, what, eight years now?

 True, we have gone through a number of releases in the last year.  Of course
 windows has also gone through lots of service packs etc.  But regardless, in
 both cases basically one release builds on another, so you are looking at
 targeting release X through Y and whatever number of intermediate steps
 there are between is not that much of an issue (though you will certainly
 want to be testing against intermediate release to verify there are no
 surprises).

  Users are much more educated and
  experienced in what to expect. At work, I, like many users
  (hopefully), just pick up the phone or send an email, and the
  problem will be taken care of.
  On a mobile device however... it just kindof ought to work, which
  isn't an unreasonable expectation. Being facetious with the backwards
  logic, the level of support that Google set aside to support the
  release of the N1 seems to confirm that idea.

 Sorry I am really not following this part. :}  Yes, you should be able to
 just pick up a phone and use it, and for the most part that is the case (as
 long as developers properly mark their minSdkVersion to not be visible on
 older platforms, and the occasional manufacturer-specific bug here and
 there).  I don't know how much support you think Google set aside for the N1
 (was it large or small?  support for what?) so I am pretty lost there.

  As far as OS X goes, during a couple of years of transition, Apple
  supported fat binaries just like they did when they switched
  OpenSTEP from Motorola to Intel a decade earlier. There's experience
  with that, and in the mobile environment, this is all new stuff and
  needs to be managed accordingly, IMHO.

 Sure and when 1.6 came out to introduce new screen support, it also included
 a lot of compatibility design and code to ensure that existing applications
 would work on the new screens.  (Or when not possible, such as QVGA screens,
 require that applications be explicitly updated and marked as compatible
 with them before allowing them to be available to users of those devices).

 What's different here?

  I want to add, no question of course, it would be unjust to criticize
  anybody that an expectation wasn't set that Android would be subjected
  to a degree of fragmentation when Android was first released
  wayback. Yet, here we are, and it would be disappointing to see the
  issue glossed over.

 I'm not sure how things are being glossed over...?

 --
 Dianne Hackborn
 Android framework engineer
 hack...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support, and so won't reply to such e-mails.  All such
 questions should be posted on public forums, where I and others can see and
 answer them.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 1:04 PM, Alberto albertovi...@gmail.com wrote:

 Dianne: I understand the issue with manufacturers and drivers, but
 even if manufacturers have to prepare the updates for each handsets,
 wouldn't be possible for Google to distribute those updates through
 their own channels instead of going the carriers' way, for example,
 correct me if I'm wrong in any of this:


If a manufacturer has a working, tested, stable update for their phone, then
Google would provide little no additional help here by distributing the
update.


 1. Google releases the source code
 2. Manufacturers customizes it for their handsets (drivers, etc)
 3. They send it back to Google
 4. Google updates most Android phones through their own channel at the
 same time, very quickly most phones are running the latest version


This just isn't going to happen.  Have you seen the number of devices that
are being announced?  It is simply not scalable to have Google or anyone
sitting in the middle of this trying to manage updates created by
manufacturers for various devices, for all the involved manufacturers.

And this just doesn't help.  The main issue is manufacturers creating and
testing new builds for their phones.  Distribution is relatively trivial
next to that.


 With all that said, even if there's nothing Google can do about the
 updates, a companion desktop application for Android would help keep
 the platform together, kind of like the lowest common denominator that
 every Google Experience phone can plug into.


I think we are really much more interested in over-the-air updates than
tying all of this through a desktop channel.  That is really a much better
way to deliver updates: for a particular device, you have a much higher
percentage of users applying the updates.  (Unless you force them to
regularly interact with a desktop application that takes care of the
updates, but that seems very undesirable to me.  Not that better desktop
support wouldn't be good for some things like media, but it shouldn't be
anything you need.)

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 3:10 PM, Christine christine.kar...@gmail.com wrote:
 It's good to see Google staff take this issue seriously :-)

Yeah, right.

 I'll repeat my personal opinion that fragmentation will not be so much
 of an issue, unless you desperately need 2.x features in your app, in
 which case you'll have to accept a 1% market share of your app.

My Google Analytics says:

SDK Versions:

1.6 - 36.97%
2.0.1 - 35.53%
1.5 - 26.02%
2.1 - 1.20%
2.0 - 0.28%

Screen Resolutions:

320x480 - 45.85%
480x854 - 31.74%
480x320 - 16.69%
854x480 - 3.73%
480x800 - 1.15%
800x480 - 0.24%

Four or five SDK versions multiplied by three or four screen
resolutions makes testing an infinitely long task.  I'm not sure how
anyone could look at the current SDK version + screen resolutions
permutation and say it's not fragmented.  And that's not even counting
different phone hardware I don't have in hand to test on when a user
complains.

Supporting Android is a nightmare right this minute, and it will only
get worse from here.  The only option I have as an independent
developer is to go with the biggest numbers and hope the minorities
don't kill my app off with Marketplace comments I can't respond to.


-- 
Greg Donald
destiney.com | gregdonald.com
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

There is absolutely no need for you to turn that into a matrix and test
every combination. Do you work on 480x854 screens? Great, you have that
covered regardless of the platform. And if you support 480x854, you must
have already tested 854x480, since any device can be switched between
landscape and portrait.

And in fact listing the different screen resolutions like that also makes
things a lot more complicated than needed.

If you want to work on the bulk of current devices, here is what you want to
test:

(1) Platform versions: 1.5, 1.6, 2.x (pretty soon just 2.1; 2.0 and 2.0.1
are on the way out). Most important are the lowest and highest versions to
be supported; intermediate ones can be given a cursory sanity check.
(2) Screen densities: test on a medium (HVGA) and high (WVGA) density to
make sure you are handling them correctly. Throw in QVGA if you want to
support small screen / low density devices.
(3) Screen sizes: make sure your app works on the smallest and larger screen
sizes you want to support. For example if you want to cover all current
devices, 240x320 low density and 480x854 high density will cover it.

So you should be able to fairly easily get away with testing: 1.5 HVGA, 2.1
HVGA, 2.1 480x854, and add 1.6 QVGA if you want to support small screens.
Spot check other variations as desired (and knowing what your app does that
it might get into trouble with).

On Mon, Jan 18, 2010 at 1:41 PM, Greg Donald gdon...@gmail.com wrote:

On Mon, Jan 18, 2010 at 3:10 PM, Christine christine.kar...@gmail.com
wrote:
It's good to see Google staff take this issue seriously :-)

Yeah, right.

I'll repeat my personal opinion that fragmentation will not be so much
of an issue, unless you desperately need 2.x features in your app, in
which case you'll have to accept a 1% market share of your app.

My Google Analytics says:

SDK Versions:

1.6 - 36.97%
2.0.1 - 35.53%
1.5 - 26.02%
2.1 - 1.20%
2.0 - 0.28%

Screen Resolutions:

320x480 - 45.85%
480x854 - 31.74%
480x320 - 16.69%
854x480 - 3.73%
480x800 - 1.15%
800x480 - 0.24%

Four or five SDK versions multiplied by three or four screen
resolutions makes testing an infinitely long task. I'm not sure how
anyone could look at the current SDK version + screen resolutions
permutation and say it's not fragmented. And that's not even counting
different phone hardware I don't have in hand to test on when a user
complains.

Supporting Android is a nightmare right this minute, and it will only
get worse from here. The only option I have as an independent
developer is to go with the biggest numbers and hope the minorities
don't kill my app off with Marketplace comments I can't respond to.

--
Greg Donald
destiney.com | gregdonald.com

--
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
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

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.



On Jan 18, 12:45 pm, Dianne Hackborn hack...@android.com wrote:
 On Mon, Jan 18, 2010 at 11:58 AM, JP joachim.pfeif...@gmail.com wrote:
  http://android-developers.blogspot.com/2009/04/backward-compatibility...
  This means having to cut off users on older Android releases, no?

 Um.  No?  The entire article is about how to use newer APIs while remaining
 compatible with older platforms.  Am I missing something?

  Kevin illustrates the problem nicely.

 What is that exactly?  I see him talking about incompatible manufacturer
 customizations and how fixing those are the responsibility of the
 manufacturer (true), about newer platform versions being compatible with
 older ones and maintaining support for older ones not being a big deal, and
 concern about minSdkVersion not filtering app from older platforms which
 should definitely not be true.


Perhaps I misread Kevin. Let me paddle back up a few posts.
As apps and the underlying platform evolve, third party devs can end
up painted in the corner, leaving only bad choices. Mostly it ends up
locking users on Android 1.x out of new features, possibly leaving
them completely behind, if these new features require changes that a
dev is not able/willing to carry through back to 1.x.
If carriers/manufacturers OTOH stepped up to maintain Android and pull
their customers up through different versions, we would indeed be able
to keep most every user on board. I feel we need this focus over a
reasonable time span, at least for the duration of the contract period
(two years typically). Here we are and some customers feel like
they've been obsoleted six months into a two year contract... And that
just one of these nagging issues that just don't get tackled. Of
course one couldn't point at a single reason why things seem kindof
gloomy, because it's a death-by-a-thousand cuts situation. The N1
release... Going by the complaints, effective support seems
unavailable, especially with the problem the device has. Or pulling
the Market out of the hat - with its wide range of long standing
issues. The upgrade last year was a step in the right direction, but
so much more remains to be done. The list goes on and on and it just
seems Google has no traction to get stuff done, for reasons unknown
and/or unpublished.
-- 
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

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.



On Jan 18, 1:41 pm, Greg Donald gdon...@gmail.com wrote:

 Screen Resolutions:

 320x480 - 45.85%        
 480x854 - 31.74%
 480x320 - 16.69%
 854x480 - 3.73%
 480x800 - 1.15%
 800x480 - 0.24%

 Four or five SDK versions multiplied by three or four screen
 resolutions makes testing an infinitely long task.  I'm not sure how
 anyone could look at the current SDK version + screen resolutions
 permutation and say it's not fragmented.  


At least as far as the argument of screen sizes is concerned -
personally I don't count that as an argument in support of
fragmentation or anything. At least in that regard someone had the
foresight to anticipate this coming the emulator offered multiple
screen sizes all the way back at the start, so everyone could/should
have been prepared for this.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

2010-01-18 Thread Romain Guy

And we've warned developers many times to use the dip unit, to not
hard code coordinates, etc.

On Mon, Jan 18, 2010 at 2:18 PM, JP joachim.pfeif...@gmail.com wrote:


 On Jan 18, 1:41 pm, Greg Donald gdon...@gmail.com wrote:

 Screen Resolutions:

 320x480 - 45.85%
 480x854 - 31.74%
 480x320 - 16.69%
 854x480 - 3.73%
 480x800 - 1.15%
 800x480 - 0.24%

 Four or five SDK versions multiplied by three or four screen
 resolutions makes testing an infinitely long task.  I'm not sure how
 anyone could look at the current SDK version + screen resolutions
 permutation and say it's not fragmented.


 At least as far as the argument of screen sizes is concerned -
 personally I don't count that as an argument in support of
 fragmentation or anything. At least in that regard someone had the
 foresight to anticipate this coming the emulator offered multiple
 screen sizes all the way back at the start, so everyone could/should
 have been prepared for this.

 --
 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




-- 
Romain Guy
Android framework engineer
romain...@android.com

Note: please don't send private questions to me, as I don't have time
to provide private support.  All such questions should be posted on
public forums, where I and others can see and answer them
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 3:54 PM, Dianne Hackborn hack...@android.com wrote:
 There is absolutely no need for you to turn that into a matrix and test
 every combination.  Do you work on 480x854 screens?  Great, you have that
 covered regardless of the platform.

But not hardware, different phones behave differently sometimes, even
with the same resolution.

 (1) Platform versions: 1.5, 1.6, 2.x (pretty soon just 2.1; 2.0 and 2.0.1
 are on the way out).

Low as they are, my stats show 2.0 and 2.0.1 are ramping up, not down.

 Most important are the lowest and highest versions to
 be supported; intermediate ones can be given a cursory sanity check.

Cursory sanity checks still require firing up yet another emulator.
This takes more than two minutes even on a smoking fast i7 machine
like mine.

 So you should be able to fairly easily get away with testing: 1.5 HVGA, 2.1
 HVGA, 2.1 480x854, and add 1.6 QVGA if you want to support small screens.
  Spot check other variations as desired (and knowing what your app does that
 it might get into trouble with).

Even when giving it just some half-hearted effort like you suggest,
that's still a minimum of 3-4 emulators.  That's still a ton of
testing time, especially for a non-trivial app with lots of different
execution paths.


-- 
Greg Donald
destiney.com | gregdonald.com
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

On Mon, Jan 18, 2010 at 4:18 PM, JP joachim.pfeif...@gmail.com wrote:
 At least as far as the argument of screen sizes is concerned -
 personally I don't count that as an argument in support of
 fragmentation or anything. At least in that regard someone had the
 foresight to anticipate this coming the emulator offered multiple
 screen sizes all the way back at the start, so everyone could/should
 have been prepared for this.

You design a game for 480x320 and so then what do you do for 854x480?
It looks hideous having the extra space there.  Some apps you can
think of something to do with the extra space, but some you can't.  On
the ones I can't I end up centering things both ways and leave the
extra space sitting there.

The reverse scenario also exists, you build a game for 854x480 and
then what do you do to support the less wide screens?  Smush things
down, spend a lot of time make alternate graphics, what?

It's a mess.


-- 
Greg Donald
destiney.com | gregdonald.com
-- 
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

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.



On Jan 18, 2:29 pm, Greg Donald gdon...@gmail.com wrote:
 On Mon, Jan 18, 2010 at 4:18 PM, JP joachim.pfeif...@gmail.com wrote:
  At least as far as the argument of screen sizes is concerned -
  personally I don't count that as an argument in support of
  fragmentation or anything. At least in that regard someone had the
  foresight to anticipate this coming the emulator offered multiple
  screen sizes all the way back at the start, so everyone could/should
  have been prepared for this.

 You design a game for 480x320 and so then what do you do for 854x480?
 It looks hideous having the extra space there.  Some apps you can
 think of something to do with the extra space, but some you can't.  On
 the ones I can't I end up centering things both ways and leave the
 extra space sitting there.

Of course easier said than done, but an element of scaling needs to be
in place. Hard to do really well, while devices smaller than 480x320,
like the Tattoo, just wouldn't make the cut.

-- 
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

[android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.

2010-01-18 Thread Piotr

You are f** right. And I'm just ungry.

Android is going stright forward J2ME way - milions of devices,
thousands profiles, screen sizes, controls, etc..

I think, the biggest Java/Android advantage - one code for all devices
is slowly vanishing.

I tried to fix some problems with my app on new devices. But you can't
bugfix, without real device, when your app works on all emu possible
SDK's without problems.

I'm tired of that shit.


So, small developers like me, that do not own thousand devices to
test, are wasting more and more our time for testing, tuning, special
custom design, bugfixing for new devices each day.

The problem is growing and I'm sure, that future testing costs will be
BIG.

I'm jumping out of that train to nowhere..


On 17 Sty, 05:06, Alberto albertovi...@gmail.com wrote:
 UPDATE: At first this was going to be just a call to fix the updating
 process, but I've realized is not just the updates Google needs to
 take control of.

 Now is the time to address the fragmentation issue that's starting to
 plague the platform, before there are hundred of handsets and the
 whole thing spins out of control. I believe we've seen enough evidence
 that the updating process through the carriers doesn't work, many
 phones are left behind and the whole thing is a mess, today we're
 already talking about the next update (2.5 Froyo?) while there are
 phones out there stuck on 1.5, the fragmentation is only going to get
 worse as we move on.

 Imagine when 3.0 gets here, and we have hundreds of handsets with 1.5,
 1.6, 2.1, 2.5, 2.7, 3.0 some with Sense UI, MotoBLUR, etc. It's going
 to be hell for developers and even more confusing for consumers,
 driving everybody away from the platform. You guys need to take
 control of this at least for the Google Experience phones. I'm not
 sure if Google updating the handsets directly would bring legal issues
 with the carriers/manufacturers, if it would, please enlighten me.

 So how do we fix this? I'm pretty sure you guys have already thought
 about this and I wouldn't be surprised if a solution was coming soon,
 since it''s such an obvious problem. However, here's my two cents, the
 solution is very simple, a desktop application for syncing/updating/
 media playback/android market/amazon mp3, lets call it Android HQ or
 Android Home for the sake of argument.

 The updates would be available to consumers as soon as they're
 released, instead of months, years, or never depending on carriers.
 This way most users would've the latest version as well as the
 developers would have the latest SDK, developers would be able to take
 advantage of the new APIs each updates bring and innovate faster,
 instead of spending time supporting older versions.

 Android HQ would also address the next two biggest problems with the
 platform, they're: media ecosystem and media syncing/backing. Also,
 the Android Market badly needs a desktop client.

 The fragmentation issue is the biggest obstacle the platform is facing
 today and it will most likely decide its success, I've sensed a couple
 of times that Google stance on these issues is to let manufactures/
 carriers make the decisions on a phone to phone basis (multi-touch
 anyone?) but that won't work, it'll eventually slow the momentum we
 have now and kill the platform (WinMo?) Google needs to have a more
 hands-on approach to Android if it wants it succeed.

 Anyway, the guys/gals in the Android Team want the platform to succeed
 as much as me, I'm sure they've given this a lot of thought, and a
 solution is probably on the works.
-- 
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

Re: [android-developers] Re: ATTENTION ANDROID TEAM: Take back control of Android.