Be compatible with the old DownloadProvider behavior of being able to
operate on content URIs returned from .insert()
Bug: 3242328
Change-Id: I7dad15ac0fefa867c3c8a33a579fc9899ac80262
- upadte documentation for rotation vector
- update method dealing with rotation vector to deal with 4 components
- virtual rotation-vector sensor reports all four components
- improve SensorManager documentation layout
Whent he 4-th component of the rotation-vector is present, we can save
a square-root when computing the quaternion or rotation matrix from it.
Change-Id: Ia84d278dd5f0909fab1c5ba050f8df2679e2c7c8
- GetTechnology() used a binary search, but the array was linked to another
array (extras) which was not sorted. So made it linear.
- The tag technologies were instantiated with a null NfcAdapter.
Change-Id: Iae15169a89155c3a5c9f81824f809d6010ebac01
This function doesn't use the same reference coordinate system used
for the rotation matrix, unlike what the documentation previously
stated.
Change-Id: I38abeb74540d33b67f72993b54d7a00a73588dde
Plugins like Flash draw directly to the screen on top
of all other views - including the fullscreen HTML5 video
view. This means that if you start an HTML5 video on a page
also serving a flash clip then flash will obscure the video.
This patch hides plugin views before start the video and shows
them again when the VideoView is destroyed.
Bug: 3183521
Change-Id: I9839c47e9d64b081651b952057e9283630362b29
extract mode IME window
Make the SelectionModifierCursorController track its show/hide state
more accurately in the presence of an extract mode IME.
Lazily initialize CursorControllers so that we don't end up creating
them for various TextViews where they are not needed.
Change-Id: Ib76a95d9e7669016cf11b8b0add8843b438068ea
request a layout when asking the transparent region to be recomputed, without this
it may never happen, since the transparent region is only calculated during layout.
this also fixes an issue where some fullscreen apps will run slower than expected
because their transparent region is never processed.
Change-Id: Iba187ef7b23f08ad3454aaa6707a3d262551e30c
The implementation was guarenteed to cause deadlock when a timeout was set.
Change-Id: I59444ea784eb9057c6c4c9e9123f558b3ef5eef6
Signed-off-by: Nick Pelly <npelly@google.com>
We were telling the app, but we weren't saving the data for ourselves.
This also tells them to re-scroll when there's a new size.
Bug: 3144373
Change-Id: I9d12b714119ff02dd7d7f1cfa997d8a44475b9e9
We are leaving enough API so that you can see when any Tag is discovered,
get its ID, and get its NDEF messages.
But for advanced use - creating tag connections and writing messages - we have
2 problems. Firstly a lot of the code is untested
(RawTagConnection.transceive()), or in some cases known not to work
(NdefTagConnection.write()). Secondly, there is still debate about how to
best expose information about Tags.
The set of data/methods exposed for a Tag changes completely depending on the
tag technology. There may be multiple sets of technology implemented in a
single tag. Tag A may have technology X and Y, Tag B may have technology Y
and Z. Furthermore, some NFC controllers will be not be able to use all
technologies, and so Android Device 1 may see technology X and Y on Tag A but
Android device 2 may only see technology X. So we have a pretty challenging
set of constraints to work under, and we are not convinced the current Tag and
NdefTag class is the best approach going forwards.
The Tag application should be able to remain unbundled, since it just needs to
get incoming NDEF Messages.
Change-Id: Ic09f094f33794e10f8d730fffe011c9a5957e0ac
Signed-off-by: Nick Pelly <npelly@google.com>
