* commit '9a8df8054b2e38a27d8e8e6b17365979218f0e3f':
docs: revise javadocs for sip add a package description, revise class descriptions and edit some method docs
* commit '1112632a41462c5dd34c7af9f67b88188a520517':
docs: revise javadocs for sip add a package description, revise class descriptions and edit some method docs
For apps targetting Honeycomb SDK or above, make network usage on the
main thread (aka event thread, Looper thread, UI thread) be fatal.
If an app is targetting a previous SDK version, they're grandfathered
into the older (lack of) rules.
Bug: 786847
Change-Id: Ia4ae77b8369567ee526c96b930d523bc722b0bc9
These are loaded by the first WebView to be instantiated and read
over JNI by libchromium in external/chromium/android/app/l10n_util.cc
Change-Id: I43d6e5a061691689d28cba2697fedcd27548af08
In earlier Android versions, Quick Search Box set this setting,
and the browser and QSB read it. Now the Browser has stopped
using it, and QSB has been unbundled and removed from the system
settings UI.
Applications that show web suggestions should have their own settings
to control it instead.
Bug: 3021480
Change-Id: I4e62bf26944287f804e50eb93843484a0356fffb
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>
The way StrictMode is used during development, just dropboxing
violations, could be a little more optimal, taking the
ActivityManagerService call off the main thread. But we can only do
this safely in the case where that's the only penalty.
Data suggests this call, despite being async, still takes around 30
milliseconds. This isn't a major win, and arguably it might be a
_better_ idea to slow down people's event loops more and further jank
up their animations on violations, but I thought any less overhead
from StrictMode, the better.
Change-Id: Iad9cce1cb4a084fa64abc4b5e1b4f3bff6a08c94
The code for the new always-there status bar was a bit too brute-force,
and also impacting things like the IME. We now implement this by
actually having an explicit concept of "display size" that the status bar
can carve out from everyone else.
Change-Id: I1963d0b07f52e8d8dc3c836227da9bf5d3f2e8b9
