[Android] Support SPen events

content/public/android/java/src/org/chromium/content/browser/ContentView.java

Index: content/public/android/java/src/org/chromium/content/browser/ContentView.java
diff --git a/content/public/android/java/src/org/chromium/content/browser/ContentView.java b/content/public/android/java/src/org/chromium/content/browser/ContentView.java
index ac54c16427643e9dac5981c6190ce6c08be2d646..8143661003c0024e597de103ecb9da1e01941427 100644
--- a/content/public/android/java/src/org/chromium/content/browser/ContentView.java
+++ b/content/public/android/java/src/org/chromium/content/browser/ContentView.java
@@ -129,6 +129,18 @@ public class ContentView extends FrameLayout
 
     @Override
     public boolean onTouchEvent(MotionEvent event) {
+        // S-Pen support: convert to normal stylus event handling

[Yaron, 2014/07/11 21:40:27]

Should this code be in CVC instead? This codepath isn't reached by webview

[Changwan Ryu, 2014/07/11 22:14:20]

OEMs can add the conversion logic in WebView.java separately. Do we still want
to move it there?

[Yaron, 2014/07/14 17:15:48]

I guess I'm worried about other programmatic invocations as well and don't
really know whether they potentially need this special handling. +dtrainor who
would have a better idea

[David Trainor- moved to gerrit, 2014/07/15 00:38:08]

We recently moved the logic from onTouchEvent here to ContentViewCore.  I'd
rather we keep this class as dumb as possible and move this logic to
ContentViewCore.  If we decide we don't want this working on WebView we can
special case this and move it back IMO.

[Changwan Ryu, 2014/07/15 01:05:07]

Sounds good. Done.

+        final int spenActionDown = 11;

[jdduke (slow), 2014/07/11 14:47:38]

I have a few worries about this.  

Suppose Vendor A has also defined some custom action types for their flavor of
Android, just as Samsung has done. Suppose these types happen to coincide with
these spen action types, but in a conflicting way. There's really no way for us
to know if this will happen short of shipping Chrome and waiting to hear about
any disasters, but the bugs could be more subtle and fly under the radar for a
while. 

Or suppose Samsung decides to change these constants down the road via an OTA
update.  Are the constants documented anywhere? Perhaps in a public SDK?

Does the spen have a corresponding ACTION_CANCEL type?

[Changwan Ryu, 2014/07/11 22:14:20]

I think this is a valid concern. Let me add OEM check.
Let me check these two with the OEM who requested this.

[jdduke (slow), 2014/07/11 22:17:40]

OK, to summarize some of the downstream and offline discussion: if we have a
sufficiently conservative check for both the SPen and Samsung device (using a
combination of Build.* properties and perhaps the "com.sec.feature.spen_usp"
system feature), the risk is greatly reduced.

Would such a check be worth putting somewhere like ApiCompatibilityUtils.java?
ApiCompatibilityUtils.isSPenSupported()? Probably use a static instance variable
to avoid doing the check work repeatedly.

[Changwan Ryu, 2014/07/11 23:06:35]

ApiCompatibilityUtils is mostly concerned about Android API compatibility, so I
wasn't sure if we'd want to change the semantics of the class.
So I've ended up adding isSpenSupported() to ContentView.java. Also, it's not a
static as it calls getContext(), but it refers to static variables.

+        final int spenActionUp = 12;
+        final int spenActionMove = 13;
+        int action = event.getAction();
+        if (action == spenActionDown) {
+            event.setAction(MotionEvent.ACTION_DOWN);
+        } else if (action == spenActionUp) {
+            event.setAction(MotionEvent.ACTION_UP);
+        } else if (action == spenActionMove) {
+            event.setAction(MotionEvent.ACTION_MOVE);
+        }
         return mContentViewCore.onTouchEvent(event);
     }