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
This option was disabled when doing fixed viewport.
This is fixed with the intention to show at least overview scale,
which will be also fine with phone.
issue:3131279
Change-Id: I2e65d40a90a04f2ca72882fec8096dd8a0d81cb0
The object that carries drawing data between WebViewCore and WebView
uses ambiguous variable names that do not fully convey the meaning
of the values. This change updates those names to make it clear to
the reader what the intention of those values is.
Change-Id: I5a403d44881e1fad366f3ec9930ee59134eccd88
You can now call goAsync() and move your work to a background thread.
If you are that kind of receiver. You weirdo.
Also allows SharedPreferences.apply() to be committed off the main
thread after returning from onReceive().
Change-Id: I27f975910e28f230ababcaeb551eb9a78ec4fc76
Certain fields in Animator are statics, like the list of current animations and the
main handler. However, since there may be >1 UI thread per process, these should really
be ThreadLocal variables, so that they are local to each UI thread. For example,
most animators will cause an invalidation in the view hierarchy, which can only
happen in the UI thread for that view.
Change-Id: I42be61c781ffac97b527f78ce1ffc2e0cdc42999
