Per RFC 4330, a NTP server response should be discarded when:
- the stratum is 0 (unspecified), or
- the leap indicator is 3 (unsync'ed), or
- the mode is not 4 (server) / 5 (broadcast), or
- the transmitted time is 0.
Update SntpClient so that such responses would be discarded.
Additionally:
- make some variables suitably "final"
- enable logging
- add alternate requestTime() for testing
- add some miniscule test coverage
Cherry-picked from Jerry Wong's
https://partner-android-review.googlesource.com/#/c/460074
Bug: 24719581
Change-Id: Id11a79a6e53ce95500ed4b4d691a29c260666f6c
An initial sorting step before applying modifiers to the ChooserTarget
scores provided by apps was backwards, causing subsequent target
scores to be heavily penalized. Targets are then heavily influenced by
the lowest score in the set relative to the targets from other apps.
Bug 25013559
Change-Id: I39d5d7c601712fc6a19e694d5846d2c8d17a214f
With the original logic, if an app creates a system window, when the
user goes to home screen, the system window will be still there and
become unable to receive input events, because the system window will
be also changed to the stopped state with the app window, and the
current logic of ViewRootImpl forbid a stopped window receiving input
events.
This change prevents assigning the token of the app window to system
windows created by the app, so that when the app goes to the stopped
state, its system windows won't be affected (can still receive input
events).
This change is related to the following changes:
a5d29971f815ed2754a3c3672cd3f741725dedc3
Bug: 24967303
Bug: https://code.google.com/p/android/issues/detail?id=189710
Change-Id: I515e47bafcf39a2b1bdf92f11f623bef8fb6263c
With the original logic, if an app creates a system window, when the
user goes to home screen, the system window will be still there and
become unable to receive input events, because the system window will
be also changed to the stopped state with the app window, and the
current logic of ViewRootImpl forbid a stopped window receiving input
events.
This change prevents assigning the token of the app window to system
windows created by the app, so that when the app goes to the stopped
state, its system windows won't be affected (can still receive input
events).
This change is related to the following changes:
a5d29971f815ed2754a3c3672cd3f741725dedc3
Bug:
https://code.google.com/p/android/issues/detail?id=189710
Change-Id: I515e47bafcf39a2b1bdf92f11f623bef8fb6263c
In order to provide pixel perfect movement of SurfaceViews
'within' other views (e.g. scrolling) we need to be able to
synchronize the attached (parent window) painting with the
movement of the SurfaceView (recall, SurfaceViews are positioned
behind their attached windows and the parent must render a
transparent region for the SurfaceView to appear). Provide
a new WindowManager method to reposition an attaching window
(that is to say, a window which has an attached window like
SurfaceView) and defer the transaction until the parent frame.
SurfaceView is hooked up to use this for movement. This is still
'racy' in the hardware accelerated case as the render thread
could be on either side of dequeing the frame we are working on.
Change-Id: Ic33915043380ab8cd9eb4920e224b35234ed867d
We are dropping CAP_BLOCK_SUSPEND since that prevents correct suspension in
Chrome OS. This change makes it so that it only requests that capability if it
is not running inside a container.
TEST=Android boots correctly
BUG:24952794
(cherry picked from commit 5e38447a9bf81bb7d58d33c71498495e1e0f575f)
(cherry picked from commit dc3943951ee475ef09cc7a4825368f9b707e1344)
Change-Id: If39357f22955442d5532d1408ce74360384521bb
Right now, it only supports I-beam on EditText, but further
rules will come in the future.
The png files for the icons are from chromium.
Bug: 24180385
Change-Id: I8de4ec8a5412b4830c08aa232c5083841c5c751c
