New multitouch patch, fully backwards-compatible and low impact

84 views
Skip to first unread message

luke

unread,
Jan 13, 2009, 4:53:26 PM1/13/09
to android-platform
I have put together a new patch for supporting multitouch scaling on
the G1.

http://web.mit.edu/~luke_h/www/Android_MultitouchV2.zip (driver
source, boot.img containing a rebuilt kernel, and a demo app .apk all
included)

This version is much less invasive than the previous patch. I pushed
all multitouch support into the synaptics driver, and only have the
driver report a single event for multitouch situations, consisting of
the x and y coords set to the midpoint between the two touch points,
and the size field of the event set to the distance between the touch
point and each finger (i.e. the radius of stretch). Size == 0 when
there is only one finger on the screen. This patch is 100% compatible
with all current apps and the Android event pipeline, as far as I can
tell. Apps can be written to detect multitouch events by checking the
size field, and if it is > 1.0 (the max value returned by the current
driver, although this value appears to just consist of noise
currently), then the program can initiate a multitouch operation.
Under the new system, the size values stored in MotionEvents are in
screen coordinates just like x and y.

From a user standpoint, this patch could easily give multitouch
scaling in MapViews and WebViews, but does not allow for more
complicated operations such as rotation (see my previous post for the
reason why).

Comments please from core framework developers? I understand a driver
was checked into git for a "real" iPhone-style multitouch screen a
while back, but there doesn't appear to be any UI code checked in for
it yet, and obviously there is no announced device. Could something
like this be pushed upstream in the meantime though to at least
support multitouch scaling on the G1? Or is this unlikely to ever
pass?

Thanks,
Luke Hutchison

Dianne Hackborn

unread,
Jan 13, 2009, 5:01:40 PM1/13/09
to android-...@googlegroups.com
Hi, this is really cool work, but I don't think we would accept something like this as a patch.  At the very least, re-using the size field to report pseudo-multi-touch information is a pretty big hack.

The API I would expect to see for multi-touch would be something along the lines of a new set of action codes for when additional fingers are down, moved, or released, and a new field on MotionEvent for which finger that event is for.  (So it would always be 0 for the current action codes, and some value 1-n for the new action codes, where n is the maximum number of fingers that can be detected.)  Then each finger would be a new distinct MotionEvent stream, which would be delivered separately and the ones with the new action codes would be ignored by existing applications.
--
Dianne Hackborn
Android framework engineer
hac...@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.

Jean-Baptiste Queru

unread,
Jan 13, 2009, 5:06:33 PM1/13/09
to android-...@googlegroups.com
On the other hand, if the panel can track all fingers in a single
processing pass, it'd be unfortunate to report that as multiple
events: at some point in time the app would be in a state that doesn't
match anything that the screen has ever read, i.e. where it has the
new location for one finger but the old location for the other one.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

luke

unread,
Jan 13, 2009, 5:08:32 PM1/13/09
to android-platform
What is the size field intended for currently?

How do action codes work? Can you just specify which codes your app
is listening for? It sounds like you are describing some sort of "opt-
in" filter system.


On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> Hi, this is really cool work, but I don't think we would accept something
> like this as a patch.  At the very least, re-using the size field to report
> pseudo-multi-touch information is a pretty big hack.
>
> The API I would expect to see for multi-touch would be something along the
> lines of a new set of action codes for when additional fingers are down,
> moved, or released, and a new field on MotionEvent for which finger that
> event is for.  (So it would always be 0 for the current action codes, and
> some value 1-n for the new action codes, where n is the maximum number of
> fingers that can be detected.)  Then each finger would be a new distinct
> MotionEvent stream, which would be delivered separately and the ones with
> the new action codes would be ignored by existing applications.
>
>
>
> On Tue, Jan 13, 2009 at 1:53 PM, luke <luke.hu...@gmail.com> wrote:
>
> > I have put together a new patch for supporting multitouch scaling on
> > the G1.
>
> >http://web.mit.edu/~luke_h/www/Android_MultitouchV2.zip<http://web.mit.edu/%7Eluke_h/www/Android_MultitouchV2.zip> (driver
> hack...@android.com

Jean-Baptiste Queru

unread,
Jan 13, 2009, 5:14:08 PM1/13/09
to android-...@googlegroups.com
Another problem is that if you put a finger down (finger 0), then
another one (finger 1), then lift the first one, the only finger being
tracked is now finger 1, and that might not work that well with
existing apps.

JBQ

Dianne Hackborn

unread,
Jan 13, 2009, 5:15:13 PM1/13/09
to android-...@googlegroups.com
On Tue, Jan 13, 2009 at 2:08 PM, luke <luke....@gmail.com> wrote:
What is the size field intended for currently?

It is the size of the finger on the screen, for ex tip or thumb.
 
How do action codes work?  Can you just specify which codes your app
is listening for?  It sounds like you are describing some sort of "opt-
in" filter system.

No, they are just the code identifying the action associated with the event -- DOWN, MOVE, UP, etc.  The app looks at the code to decide what to do with the event.

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

Dianne Hackborn

unread,
Jan 13, 2009, 5:16:24 PM1/13/09
to android-...@googlegroups.com
On Tue, Jan 13, 2009 at 2:14 PM, Jean-Baptiste Queru <j...@google.com> wrote:
Another problem is that if you put a finger down (finger 0), then
another one (finger 1), then lift the first one, the only finger being
tracked is now finger 1, and that might not work that well with
existing apps.

Whether this is reported as the first or second finger going up is an implementation detail (in the screen firmware as well as the framework).

luke

unread,
Jan 13, 2009, 5:23:06 PM1/13/09
to android-platform
On Jan 13, 5:06 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> On the other hand, if the panel can track all fingers in a single
> processing pass, it'd be unfortunate to report that as multiple
> events: at some point in time the app would be in a state that doesn't
> match anything that the screen has ever read, i.e. where it has the
> new location for one finger but the old location for the other one.

You are right, but the rate that motion events are passed along makes
this effect almost negligible... There is a lot of messiness like
this in event processing, I have come to discover...

luke

unread,
Jan 13, 2009, 5:24:11 PM1/13/09
to android-platform
On Jan 13, 5:14 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> Another problem is that if you put a finger down (finger 0), then
> another one (finger 1), then lift the first one, the only finger being
> tracked is now finger 1, and that might not work that well with
> existing apps.

Correct. This is actually a hardware limitation, and needs to be
handled with smarts at some level. Apparently the iPhone SDK leaves
it up to the user to handle this.

luke

unread,
Jan 13, 2009, 5:27:20 PM1/13/09
to android-platform
On Jan 13, 5:15 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> On Tue, Jan 13, 2009 at 2:08 PM, luke <luke.hu...@gmail.com> wrote:
> > What is the size field intended for currently?
>
> It is the size of the finger on the screen, for ex tip or thumb.

Not for the synaptics driver -- size information is passed in the
pressure field. Sometimes you can convince yourself the value gets
smaller just as a touchpoint lifts off the screen, but it's a
stretch. Also the range of values [0.0,1.0] are quantized to 15
levels at the driver level. I tried really hard to find meaning for
the value in the size field, and just couldn't believe it was used for
anything meaningful -- and certainly the information is not reliable
enough to do anything meaningful with. It is effectively just noise.

> > How do action codes work?  Can you just specify which codes your app
> > is listening for?  It sounds like you are describing some sort of "opt-
> > in" filter system.
>
> No, they are just the code identifying the action associated with the event
> -- DOWN, MOVE, UP, etc.  The app looks at the code to decide what to do with
> the event.

Oh, those codes. That makes sense as a way of building in multitouch
without creating a major new API.

luke

unread,
Jan 13, 2009, 5:29:15 PM1/13/09
to android-platform
On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> Hi, this is really cool work, but I don't think we would accept something
> like this as a patch.  At the very least, re-using the size field to report
> pseudo-multi-touch information is a pretty big hack.

No problem, totally understandable. I will probably put this out
there as a "community hack" and see if it catches on (i.e. whether
Market apps start appearing that use it). I am going to hack together
a map and browser apps that use this for scaling, and people can
choose whether or not to use this on their phone as a workaround,
until multitouch is officially available.

Thanks for answering my questions.

luke

unread,
Jan 13, 2009, 5:31:51 PM1/13/09
to android-platform
Actually I have one more question if anyone can answer it -- does
anyone know for sure if the threat of being sued by Apple really is a
barrier to getting multitouch on Android? I don't need an official
word from Google or anybody else -- I just need to know if this is
just rumor or if it is a real possibility.

Thanks!

Dianne Hackborn

unread,
Jan 13, 2009, 5:45:46 PM1/13/09
to android-...@googlegroups.com
On Tue, Jan 13, 2009 at 2:27 PM, luke <luke....@gmail.com> wrote:
Not for the synaptics driver -- size information is passed in the
pressure field.  Sometimes you can convince yourself the value gets
smaller just as a touchpoint lifts off the screen, but it's a
stretch.  Also the range of values [0.0,1.0] are quantized to 15
levels at the driver level.  I tried really hard to find meaning for
the value in the size field, and just couldn't believe it was used for
anything meaningful -- and certainly the information is not reliable
enough to do anything meaningful with.  It is effectively just noise.

If we are talking about accepting a patch (and I need to emphasize, I can't make an promises about anything here, except that the current approach will not be accepted), it can't be just designed around what the synaptics driver happens to currently do.

What you are doing is great work for shimming in a multi-touch demo that touches as little code as possible.  For a patch that would add multitouch APIs, though, the approach is much different and should result in an API that is clear and easy to understand and sufficient for a wide variety of devices.  There would also be other things to deal with, for example a way for an app to find out up-front if the screen is capable of multi-touch.

Disconnect

unread,
Jan 13, 2009, 7:08:48 PM1/13/09
to android-...@googlegroups.com
Great work btw :)

And everything I have seen says apple patented -gestures-. EG pinch to zoom, etc. So .. ymmv. But it cannot prevent general multitouch from working (ahem, ms surface) or - likely - even stretch to zoom (prior art)..

Tanu

unread,
Jan 16, 2009, 2:29:51 AM1/16/09
to android-platform
plzzz... can u tell me....
how to install the bootimage file inthe windows environmet....
how to run the multitouch event application........

thanks and regards
Tanuja
> > > Thanks for answering my questions.- Hide quoted text -
>
> - Show quoted text -

Miroslav Mandov

unread,
Jan 26, 2009, 3:09:55 AM1/26/09
to android-platform



> For a patch that would add multitouch
> APIs, though, the approach is much different and should result in an API
> that is clear and easy to understand and sufficient for a wide variety of
> devices.  There would also be other things to deal with, for example a way
> for an app to find out up-front if the screen is capable of multi-touch.
>
> --
> Dianne Hackborn


Could it be possible to add an "option" in so "settings", where the
user could select whether his device supports MT or just a single
touch? In this way Android would have this nice feature for devices
that support it, and be able to work as it is now for devices that are
not MT capable.

Dianne Hackborn

unread,
Jan 26, 2009, 1:14:36 PM1/26/09
to android-...@googlegroups.com
For hardward that doesn't support multitouch this would need to always be false, and if it does I don't see why you would want to turn it off, so I'm not sure I the point of a user setting for it...?

Miroslav Mandov

unread,
Jan 27, 2009, 7:41:53 AM1/27/09
to android-platform
On Jan 26, 8:14 pm, Dianne Hackborn <hack...@android.com> wrote:
> For hardward that doesn't support multitouch this would need to always be
> false, and if it does I don't see why you would want to turn it off, so I'm
> not sure I the point of a user setting for it...?

May be I did not explain my point correctly.
My idea was to have the MT functionality in Android OS and at the same
time to keep the existing GUI for devices that are not MT capable.
Android concept is that all applications should be compatible with all
Android devices that could lead to the bad idea to keep it only as
"single touch" platform.
Yes, it could be an "option" that the manufacturer is selecting, or
Android can select it based on the screen drivers.

Unfortunately I just saw that Apple was awarded "Touch screen device,
method, and graphical user interface for determining commands by
applying heuristics" patent:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=multi-touch&s2=multitouch&OS=multi-touch+AND+multitouch&RS=multi-touch+AND+multitouch

BTW I am using JF's 1.41 version of ADP1, which implements Luke's MT
and it works quite good.

Jean-Baptiste Queru

unread,
Jan 27, 2009, 7:51:20 AM1/27/09
to android-...@googlegroups.com
Please don't discuss patents on this list. Thanks.

JBQ

--

Dianne Hackborn

unread,
Jan 27, 2009, 12:43:17 PM1/27/09
to android-...@googlegroups.com
Well yes of course if or when multi-touch is introduced into the platform, you will NOT be able to rely on it being there.  Android will be running on devices without a multitouch screen, you can count on it.

Bob

unread,
Jan 29, 2009, 9:04:26 PM1/29/09
to android-platform
Engadget just had an interesting article that discussed the Apple
"multi-touch" patent, suggesting that pinch/zoom isn't claimed.
http://www.engadget.com/2009/01/28/apple-vs-palm-the-in-depth-analysis/

Please think about soft keyboards when considering multi-touch APIs,
where the problem isn't detecting the distance between two finger, but
rather is allowing a 2nd finger (or thumb) to come down on a 2nd key
before the first finger (or thumb) has been released. The proposed
API to provide only a centroid and the distance between fingers won't
work at all for this sort of application.

I think you'd ultimately want to package this as additional
GestureDetector subclasses, depending on whether the type of gesture
detection wanted was pinch/zoom or multiple/overlapping taps.
Keyboards (and maybe games) would use one class, browsers another.

Providing the right information from a touch panel to drive either
detector might be challenging, especially if the panel provides
'unpaired' x and y coordinates rather than individual touch locations,
but I believe it could be done.

On Jan 13, 4:08 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> And everything I have seen says apple patented -gestures-. EG pinch to zoom,
> etc. So .. ymmv. But it cannot prevent general multitouch from working
> (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
>

Dianne Hackborn

unread,
Jan 29, 2009, 9:05:44 PM1/29/09
to android-...@googlegroups.com
Please don't talk about patents on this list, thanks.

Al Sutton

unread,
Jan 30, 2009, 2:20:11 AM1/30/09
to android-...@googlegroups.com
Thread already doing the patent thing to death on -developers;

http://groups.google.com/group/android-developers/browse_thread/thread/d1970d9896878f74/3d2f85cc0f4e1205#3d2f85cc0f4e1205

It probably should go to -discuss if anyone wants to continue it.

Al.

Dianne Hackborn wrote:
> Please don't talk about patents on this list, thanks.
>
> On Thu, Jan 29, 2009 at 6:04 PM, Bob <bob....@gmail.com
> <mailto:bob....@gmail.com>> wrote:
>
>
> Engadget just had an interesting article that discussed the Apple
> "multi-touch" patent, suggesting that pinch/zoom isn't claimed.
> http://www.engadget.com/2009/01/28/apple-vs-palm-the-in-depth-analysis/
>
> Please think about soft keyboards when considering multi-touch APIs,
> where the problem isn't detecting the distance between two finger, but
> rather is allowing a 2nd finger (or thumb) to come down on a 2nd key
> before the first finger (or thumb) has been released. The proposed
> API to provide only a centroid and the distance between fingers won't
> work at all for this sort of application.
>
> I think you'd ultimately want to package this as additional
> GestureDetector subclasses, depending on whether the type of gesture
> detection wanted was pinch/zoom or multiple/overlapping taps.
> Keyboards (and maybe games) would use one class, browsers another.
>
> Providing the right information from a touch panel to drive either
> detector might be challenging, especially if the panel provides
> 'unpaired' x and y coordinates rather than individual touch locations,
> but I believe it could be done.
>
> On Jan 13, 4:08 pm, Disconnect <dc.disconn...@gmail.com

> <mailto:dc.disconn...@gmail.com>> wrote:
> > And everything I have seen says apple patented -gestures-. EG
> pinch to zoom,
> > etc. So .. ymmv. But it cannot prevent general multitouch from
> working
> > (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
> >
> > On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com
> <mailto:luke.hu...@gmail.com>> wrote:
> >
> > > Actually I have one more question if anyone can answer it -- does
> > > anyone know for sure if the threat of being sued by Apple
> really is a
> > > barrier to getting multitouch on Android? I don't need an
> official
> > > word from Google or anybody else -- I just need to know if this is
> > > just rumor or if it is a real possibility.
> >
> > > Thanks!
> >
> > > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com

> <mailto:luke.hu...@gmail.com>> wrote:
> > > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com

> <mailto:hack...@android.com>> wrote:
> >
> > > > > Hi, this is really cool work, but I don't think we would
> accept
> > > something
> > > > > like this as a patch. At the very least, re-using the
> size field to
> > > report
> > > > > pseudo-multi-touch information is a pretty big hack.
> >
> > > > No problem, totally understandable. I will probably put
> this out
> > > > there as a "community hack" and see if it catches on (i.e.
> whether
> > > > Market apps start appearing that use it). I am going to
> hack together
> > > > a map and browser apps that use this for scaling, and people can
> > > > choose whether or not to use this on their phone as a
> workaround,
> > > > until multitouch is officially available.
> >
> > > > Thanks for answering my questions.
>
>
>
>
> --
> Dianne Hackborn
> Android framework engineer

> hac...@android.com <mailto:hac...@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.
>


--
======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

Jeff Hamilton

unread,
Jan 30, 2009, 10:08:54 AM1/30/09
to android-...@googlegroups.com
Please do not discuss patents on any of the lists. Thanks.

-Jeff

Al Sutton

unread,
Jan 30, 2009, 10:23:18 AM1/30/09
to android-...@googlegroups.com
So where would you prefer discussions about specific patents and their potential effects on functionality to be discussed?

Al.

Dianne Hackborn

unread,
Jan 30, 2009, 1:12:57 PM1/30/09
to android-...@googlegroups.com
Most software engineers working at a company simply can not discuss specific patents in public forums, because of the legal repercussions.  Whenever possible, it is best simply to not know about them.

So we'd prefer if there was no talking about specific patents on these lists.  You can talk about them somewhere else, but many of the people working on Android will not be able to join you.

mike quinn

unread,
Jan 30, 2009, 2:54:04 PM1/30/09
to android-...@googlegroups.com
And therein lies the problem.

These patents do nothing but stifle innovation for the fear of legal backlash, the best people to discuss this with are the very people that cannot comment on it.

Al Sutton

unread,
Jan 31, 2009, 5:44:55 AM1/31/09
to android-...@googlegroups.com
First off I've put a blog entry up so that this can be discussed
off-list as requested;
http://alsutton.wordpress.com/2009/01/31/will-us-patent-laws-strange-android/

The only reason that software patent discussions don't take place
regularly for most "software engineers at a company" is because for most
of us they are not an issue. There are no legal repercussions because
they are not enforceable in a vast majority of the world.

If the Android team limits Androids functionality based on patents that
are only valid in the US then Android will *never* become a major player
in the mobile OS market because it will get absolutely trashed in any
comparison with products from Nokia, RIM, and all the other companies
who have non-US development shops that ship to markets outside the US.

And if nobody wants to discuss them then you're just ignoring the
elephant in the room, and I was always taught that in law ignorance is
not defence.

Al.

> > > > <mailto:bob....@gmail.com <mailto:bob....@gmail.com>>>

> > > > <mailto:dc.disconn...@gmail.com


> <mailto:dc.disconn...@gmail.com>>> wrote:
> > > > > And everything I have seen says apple patented
> -gestures-. EG
> > > > pinch to zoom,
> > > > > etc. So .. ymmv. But it cannot prevent general
> multitouch from
> > > > working
> > > > > (ahem, ms surface) or - likely - even stretch to zoom
> (prior art)..
> > > > >
> > > > > On Tue, Jan 13, 2009 at 5:31 PM, luke
> <luke.hu...@gmail.com <mailto:luke.hu...@gmail.com>

> > > > <mailto:luke.hu...@gmail.com


> <mailto:luke.hu...@gmail.com>>> wrote:
> > > > >
> > > > > > Actually I have one more question if anyone can
> answer it -- does
> > > > > > anyone know for sure if the threat of being sued by Apple
> > > > really is a
> > > > > > barrier to getting multitouch on Android? I don't
> need an
> > > > official
> > > > > > word from Google or anybody else -- I just need to
> know if this is
> > > > > > just rumor or if it is a real possibility.
> > > > >
> > > > > > Thanks!
> > > > >
> > > > > > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com
> <mailto:luke.hu...@gmail.com>

> > > > <mailto:luke.hu...@gmail.com


> <mailto:luke.hu...@gmail.com>>> wrote:
> > > > > > > On Jan 13, 5:01 pm, "Dianne Hackborn"
> <hack...@android.com <mailto:hack...@android.com>

> > > > <mailto:hack...@android.com

> <mailto:hac...@android.com <mailto:hac...@android.com>>

Jean-Baptiste Queru

unread,
Jan 31, 2009, 8:11:25 AM1/31/09
to android-...@googlegroups.com
Two words: treble damages.

JBQ

--

Al Sutton

unread,
Jan 31, 2009, 9:12:41 AM1/31/09
to android-...@googlegroups.com
Two words : No jurisdiction.

US courts can't award and enforce any penalty on a non-US legal entity
conducting business outside the US, so if Android is going to be
modified to comply with US patents when US based legal issues arise you
can be pretty sure it'll lose when it's compared around the world with a
phone not developed in the US.

Al.

Jean-Baptiste Queru

unread,
Jan 31, 2009, 9:43:45 AM1/31/09
to android-...@googlegroups.com
We're just following the guidelines established by our legal department.

JBQ

--

Bradley Young

unread,
Jan 31, 2009, 11:09:29 AM1/31/09
to android-...@googlegroups.com

And they set that guideline due to two words:

Discoverable email.

Discussions about patents are *not* the kind of thing that you want done via email.  It is quite understandable that Google has this restriction, and they host the list (not only that, but it seems that they are paying employees to participate!).  You should respect that, as you would show respect in someone else's house.

Bradley

On Jan 31, 2009 6:43 AM, "Jean-Baptiste Queru" <j...@google.com> wrote:


We're just following the guidelines established by our legal department.

JBQ

On Sat, Jan 31, 2009 at 6:12 AM, Al Sutton <a...@funkyandroid.com> wrote: > > Two words : No jurisdic...

Al Sutton

unread,
Jan 31, 2009, 11:31:26 AM1/31/09
to android-...@googlegroups.com
Don't get me wrong, I understand the restrictions you're under because
you're US based, but my concern is that because you're US based Android
will suffer.

I understand that this conversation has now gone beyond a platform issue
and onto a wider discussion about how US patents could affect android,
which is why I'd suggest any further comments can be posted on my blog
entry (http://bit.ly/UtGy) and are kept away from the Android lists in
case a specific example of a patent is needed to make a point.

Al.

Jean-Baptiste Queru

unread,
Jan 31, 2009, 11:47:14 AM1/31/09
to android-...@googlegroups.com
The majority of smartphone OSes have some part of their development
done in the US. In fact several of the most visible members of that
family are developed primarily in Santa Clara County, California.

JBQ

--

Al Sutton

unread,
Jan 31, 2009, 1:09:11 PM1/31/09
to android-...@googlegroups.com
Nokia sold 42.4% of Smarphones in Q3 2008[1]. The bulk of their
development is done in Finland, Germany, and the UK. With their US
presence mostly doing things for the local US market.

I can understand that out of the 5 or so OSes 3 may be mainly developed
in the US, so numerically the number of smartphone OSes developed in the
US is more than the number developed outside the US, but when an OS in
the non-US minority holds over 40% market share (which is more than it's
4 nearest competitors combined), I think that also says something very
important.

Al.

[1]http://compoundsemiconductor.net/blog/2008/12/global_smartphone_sales_growth.html

Muthu Ramadoss

unread,
Jan 31, 2009, 1:26:10 PM1/31/09
to android-...@googlegroups.com
Now I know why Nokia is winning. Thanks Al.

take care,
Muthu Ramadoss.

http://linkedin.com/in/tellibitz +91-9840348914
http://androidrocks.in - Android Consulting.

Jean-Baptiste Queru

unread,
Jan 31, 2009, 6:19:21 PM1/31/09
to android-...@googlegroups.com
That's interesting, it wasn't that long ago that they were trying to
recruit me in their engineering office in Boston to work on some core
technologies that ship on all their European phones, or that I was
working directly with their engineering office in San Diego on
products for the Americas (not just the US), or that a good friend of
mine was working in engineering in one of their Bay Area offices on
phone stuff that ships mostly in Asia.

Seriously, Nokia does have some significant engineering presence in
the US, and not just for the US market (though they indeed do a lot of
their engineering work outside of the US).

JBQ

--

Al Sutton

unread,
Feb 1, 2009, 3:46:33 AM2/1/09
to android-...@googlegroups.com
Nokia employed around 14,500 in their R&D departments spread throughout
11 countries. The US ones do the Rich Context Modeling and New User
Interfaces work which is also done at every other center around the
globe. R&D into on High Performance Mobile Platforms is done in the
Finland and the UK, Cognitive Radio is done in Finland. (you can get
all this from http://research.nokia.com/centers/index.html)

Some of the work on Nokias linux based tablet OS (Mameo -
http://maemo.org/) is done the US, but the huge bulk of the work on
Symbian (their main 'phone OS) has always been done in Europe (due to
it's history in Psion devices based in the UK) and is done by a company
called Symbian Software Ltd who are registered in the UK. Looking at
their development vacancies you can see they're all based in Waterloo
(which is in London in the UK), Beijing, or Bangalore. Out of the 35+
Software Engineer vacancies at Symbian not a single one is in the US
and, in fact, the US subsiduary (Symbian Inc.) has no open vacancies in
any part of the business.

Nokia do add a lot of the Symbian package such as their equivalent of
the home screen and all the apps, but the core smartphone OS and it's
features are not developed in the US, and, given the movement of OS
development from Sybian Software Ltd. to the Symbian foundation, which
is again a UK based company, it seems unlikely that will change.

Al.

Romain Guy

unread,
Feb 1, 2009, 11:45:32 AM2/1/09
to android-...@googlegroups.com
The purpose of this list is not to discuss the organization of Nokia.

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

Al Sutton

unread,
Feb 1, 2009, 3:07:27 PM2/1/09
to android-...@googlegroups.com
Which is why, several posts ago, I suggested moving this to my blog
entry at http://bit.ly/UtGy

But, if people continue to use this list as the main discussion point
I'll happily continue to respond to their points.

Al.

Dianne Hackborn

unread,
Feb 1, 2009, 4:09:07 PM2/1/09
to android-...@googlegroups.com
Note to self: do not reply to Al. :)

Jean-Baptiste Queru

unread,
Feb 1, 2009, 7:24:15 PM2/1/09
to android-...@googlegroups.com
Note to self: beware of the discussions that weave in and out of
topic, as they might suddenly turn entirely off-topic.

Romain is right, this discussion should have moved to android-discuss
a while back. Sorry for letting it fester when I should have
abstained.

JBQ

--

Muthu Ramadoss

unread,
Feb 2, 2009, 2:34:49 AM2/2/09
to android-...@googlegroups.com
Note to Self: beware of the discussions that weave in and out of topic, as they might suddenly turn entirely off-topic. Bookmark these discussions, since they are highly entertaining :)


take care,
Muthu Ramadoss.

http://linkedin.com/in/tellibitz +91-9840348914
http://androidrocks.in - Android Consulting.



Bob

unread,
Feb 2, 2009, 3:10:37 PM2/2/09
to android-platform
So can we get back to talking about the proposed API for multi-touch
events on Android? I'd really love for Dianne or one of the other
framework engineers to comment on how they'd like to see this data
passed up to applications, and in particular respond to the problem of
keeping two event streams in sync if that's the direction you'd like
to go.

I think it's pretty clear that in addition to single touch Android
devices, there will also be devices capable of multi touch input as
well, because capacitive panels that can deliver both "unpaired" x, y
coordinates as well as two or more paired x,y coordinates are becoming
available.

Dianne Hackborn

unread,
Feb 2, 2009, 3:34:27 PM2/2/09
to android-...@googlegroups.com
I already did comment to the very original message, with a rough outline of how a platform API might reasonably look.

That said, I am starting to lean towards extending MotionEvent to be able to hold multiple fingers of information.  Not by hacking it into the size field, but with new APIs that allow you to retrieve this information.

I think that's all the talking we really need to do.  If someone wants to start putting together an API, feel free to post it and we can discuss something concrete.

luke

unread,
Feb 6, 2009, 11:17:42 AM2/6/09
to android-platform
Guys -- I made the original post, put together wrote the MT hack, and
asked the ("innocent") question about patents without specifically
directing the question at Google.

Dianne is absolutely right, this multitouch hack is not right for the
platform, should not be part of (and is not intended for) a longterm
strategy. Do not rely on it for long-term multi-touch support.

Dianne and her colleagues are excellent engineers (seriously, I don't
know how you guys pulled together the entire Android stack in
something like two years, it has to constitute one of the greatest
software engineering feats of all time). I trust them to do the right
thing with this. If anyone has an emotional investment in multitouch,
help them come up with the right API. I do not have any emotional
investment in this -- I did initially but I'm done with it and I have
already moved on and don't intend to do any more work with this.

The hacked kernel is out there if you want multitouch scaling in your
browser (see JesusFreke's replacement firmware images v1.4+). This
will break a few apps (noticeably steamy window -- but I don't know
how anyone could have that app installed for more than 5 minutes...).
I don't know of any other apps that use the size field. If they do,
they should probably use the pressure field not the size field, it has
much finer granularity anyway (16-bit precision rather than 4-bit
precision).

A correction: Dianne was absolutely right that the size field *does*
work, and *does* represent size information. I was wrong. It looked
like it didn't represent size information to me because it is so
coarsely quantized (and therefore the value was highly subject to
noise). I still believe this value is not super-useful for anything
other than perhaps distinguishing between a finger touch on the screen
and a cheek touch... even finger/thumb differentiation is not good...
but regardless, with this particular touch sensor, size is redundant
and lossy compared to pressure. In future touch sensors those two
values may encode very different information however.

On the patent issues, forget I asked the question, I didn't know it
would result in the above debate. Let's give the Google guys some
credit and respect. While I hate (as much as the next person) the
fact that Google is still not as open in the development process as I
would personally like (including lack of love given to the external
bug tracker, limited influence over the decision-making process,
etc.), Google *is* doing most of the actual work, and I have also
worked at Google before as a s/w engineer, so I know that employees
there are just too busy with their own internal requirements and todo
lists to even have time to deal with the pitchfork-wielding masses.
The fact that we have several regularly-posting Google employees on
here is pretty nice.

Keep up the good work, guys/gals.



On 2 Feb, 15:34, Dianne Hackborn <hack...@android.com> wrote:
> I already did comment to the very original message, with a rough outline of
> how a platform API might reasonably look.
>
> That said, I am starting to lean towards extending MotionEvent to be able to
> hold multiple fingers of information.  Not by hacking it into the size
> field, but with new APIs that allow you to retrieve this information.
>
> I think that's all the talking we really need to do.  If someone wants to
> start putting together an API, feel free to post it and we can discuss
> something concrete.
>
> On Mon, Feb 2, 2009 at 12:10 PM, Bob <bob.eb...@gmail.com> wrote:
>
> > So can we get back to talking about the proposed API for multi-touch
> > events on Android?  I'd really love for Dianne or one of the other
> > framework engineers to comment on how they'd like to see this data
> > passed up to applications, and in particular respond to the problem of
> > keeping two event streams in sync if that's the direction you'd like
> > to go.
>
> > I think it's pretty clear that in addition to single touch Android
> > devices, there will also be devices capable of multi touch input as
> > well, because capacitive panels that can deliver both "unpaired" x, y
> > coordinates as well as two or more paired x,y coordinates are becoming
> > available.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com

Giovanni_Macigno

unread,
Mar 4, 2009, 5:13:49 AM3/4/09
to android-platform
My problem is to develop an application with multitouch. Is there a
complete API to handle multitouch? Or need i to implement an algo with
the single-touch apis that simulates multitouch?

Thanks.
Giovanni.

Jean-Baptiste Queru

unread,
Mar 4, 2009, 9:04:33 AM3/4/09
to android-...@googlegroups.com
If you're trying to develop an application with the SDK, this is the
wrong group, android-developers would be the right place (and, no,
there's no multitouch API).

If you're proposing to contribute to Android itself, you should first
discuss what application you want to contribute, who will maintain it,
why it should be part of Android, and who will develop and maintain
the framework changes necessary for your application to run.

JBQ

--

Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

Questions sent directly to me will likely get ignored or forwarded to
a public forum with no further warning.

Reply all
Reply to author
Forward
0 new messages