The Javadoc comment for class `android.content.UriMatcher` had four issues:
1. The example calls to `addURI` should not be using a leading forward slash in
the path parameter (reported by Ester Ytterbrink).
2. The sample code to construct a `UriMatcher` was incorrect because the
`UriMatcher` constructor takes a parameter (reported by Ross Light).
3. The code example for using `match` was incorrect because it showed two
parameters being passed, when `match` only takes one (reported by
Ross Light).
4. The sample `getType` implementations were incorrect because `getType` takes
a `Uri` object, not an array of `String`s.
Change-Id: I560bff6f021c13cabf736f40ff0f47a205074291
Adding more detail to the output logging to help track down issues, fixing some
download completed notification counter flakiness and making reboot test more
robust, and reducing the number of concurrent downloads in testMultipleDownloads()
to 10. After talking with Vasu, this is probably more appropriate as it is
closer to typical usage scenarios, and as a side effect should trim some
time from the test runs. Large numbers of downloads will be left for stress
testing.
Change-Id: Ie337cfe9b8d27299d70553e39c60e241ff3afe66
* commit '1112632a41462c5dd34c7af9f67b88188a520517':
docs: revise javadocs for sip add a package description, revise class descriptions and edit some method docs
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>
This patch makes the dispatcher drop all of its state when it is
disabled (when the screen turns off). This ensures that the dispatcher
does not get stuck thinking a pointer is still down if the screen
turned off while the user was touching the display (such as a fat touch
while hitting the power button).
Bug: 3098344
Change-Id: If50ef5804870aa1acd3179fd4b40e3cda58dd39d
Two bugs were counter acting each other.
- rotation matrices are on the left-hand side of multiplies
- the transform of the overlay is applied before that of the layer
Change-Id: Ia79bd368e9b719235c89ecf244ea263f01ce906a
