It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 to add a
toast window one needs to have a special token. The token
is added by the notificatoion manager service only for
the lifetime of the shown toast and is then removed
including all windows associated with this token. This
prevents apps to add arbitrary toast windows.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Ia1dae626bd9e22541be46edb072aa288eb1ae414
Skip certificates in a DirectoryCertificateSource that cannot be read to
due IOExceptions or CertificateExceptions, this prevents a NPE but
connections will still fail due to the certificate being unusable and no
valid trust-anchor existing.
This also logs the error since this really shouldn't happen.
Bug: 29997695
Change-Id: I9f7327efc302a259fb951f1f61f7fc4d647821fa
Handler has no fewer than three ways by which a message might be
handled:
[1] the msg itself contains a callback (msg.callback.run())
[2] the Handler was instantiated with a Handler.Callback
(mCallback.handleMessage(msg))
[3] the Handler instance was a subclass and could have
overridden handleMessage()
Handler#dispatchMessage() tries to find the correct way to dispatch
a message, check the above in the above order.
Bug: 21859053
Change-Id: I284cf7ace93af167d95d13b297ec42d4bed15992
also update all non-DAC builds to use the "referenceonly" flag for a cleaner output and faster build.
Change-Id: Iebd9791305479c5dc406ba3b81eaf076855bc632
This doesn't take long, so there is little reason to show it if
we didn't show the dex opt dialog.
Bug: 29643498
Change-Id: I955f9dfa233166a8a150deb2d115a591e6d82394
This CL fixes typos in JavaDoc for InputConnection.
This CL slso updates the content regarding a new API that was added in
API 25 [1][2].
[1]: Iaadf934a997ffcd6000a516cc3c1873db56e60ad
152944f490
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588
Bug: 31249896
Change-Id: Icafedb15943a84f8e5b03ef9eb3a50627d508bdd
Sync adapters were able to access the synced account without the accounts
permission which circumvents our permission model. Therefore, we require
sync adapters that don't have access to the account to get user consent.
This can be noisy, therefore we will white-list sync adapters installed
before we started checking for account access because they already know
the account (they run before) which is the genie is out of the bottle.
bug:31162498
Change-Id: I815e521778892ec592d53d086273743f1711bd17
Referred to the "android:resizableActivity" property; should
have been "android:resizeableactivity". English prose, however,
consistently uses the (preferred) spelling "resizable".
See first comment for stage location.
bug: 30566808
Change-Id: I2570ff9269b4d2dc8b11f1c98817e50726be78fc
