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
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
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
Update storage related docs on Context to be consistent, and to call
out relevant Environment methods. Start calling it "shared" storage,
and only mention external for historical reasons. Mention that there
isn't much benefit to using emulated storage over private data
directories to help guide developers to safer locations.
Point out which paths can change over time, so developers know to
only persist relative paths.
Update Environment docs to reflect how they behave for the new
class of adopted storage devices.
Bug: 24251945
Change-Id: Ie5ab337649b4740dfd7594997bbb19c4969cfd2f
