Currently, we look at network requests that are created by the
current requestNetwork API to see if they look like requests
that could have been created using the legacy
startUsingNetworkFeature API.
This causes those networks to be added to LegacyTypeTracker,
and so cause CONNECTIVITY_ACTION broadcasts, be accessible
using getNetworkInfo(int type), etc. This was done in the L
timeframe so that apps could request networks using the
then-new requestNetwork APIs and still use them using legacy
APIs such as requestRouteToHost.
However, the resulting CONNECTIVITY_ACTION broadcasts are
expensive. requestRouteToHost has been deprecated since L, and
mixing the old and new APIs was never recommended, so it's time
to delete this hack.
Bug: 22513439
Bug: 23350688
Bug: 25295964
Change-Id: Id867058446e5ee44396743d126d26fa57da0c990
This was returning false on some test keystores even when
getCertificate would correct return a certificate. Remove the check to
be consistent with how conscrypt loads trust anchors from the keystore.
Bug: 25897324
Change-Id: Ie87658a261ee7ba1cca6896e34b6c53b8abfba85
The documentation for this method says that the request can be
released using releaseNetworkRequest, but that's not true.
releaseNetworkRequest only takes a PendingIntent, and can only be
used to release a request filed with a PendingIntent.
Fix the docs to say that the request needs to be released using
unregisterNetworkCallback.
Change-Id: If044fd2d463ab8d09874172d5d56946251057a3c
This is a mechanical replacement of Context.getSystemService(String)
with Context.getSystemService(Class<T>) when retrieving InputManager.
Note those are bundled code. Hence we don't need to make sure
Build.VERSION.SDK_INT >= 23.
Change-Id: Iee47e374e1349720e3100bab33ed139e1f47c169
This is a mechanical replacement of Context.getSystemService(String)
with Context.getSystemService(Class<T>) when retrieving
InputMethodManager. Note those are bundled code. Hence we don't need
to make sure Build.VERSION.SDK_INT >= 23.
Change-Id: Icc64942ad8f11e44bf84f8d4fe476b2fdd1257f3
Also:
- add a few @Overrides where appropriate.
- some small refactoring/reformatting
Bug: 9580643
Bug: 22332501
Bug: 25824776
Change-Id: Id4f496ced4db15cd9da51c80c5d1dde06f476f54
- No longer rendering the task view to another drag view, instead we
drag the task view directly. This allows us to do a smooth transition
to and from the freeform workspace and the stack by animating the
thumbnail scale as we clip/unclip the task view.
- Removing the extra code to disable rotation while dragging since the
system does that for us already
Change-Id: I1e02c9319347aace9870eaa4983b3b87c5f0f58e
The old workflow was:
1. dumpstate starts.
2. When dumpstate finishes, it sends a BUGREPORT_FINISHED intent.
3. Shell's BugreportReceiver receives the BUGREPORT_FINISHED and issues a
system notification so user can share the bug report.
The new workflow is:
1. When dumpstate starts, it sends a BUGREPORT_STARTED with its pid and
the estimated total effort.
2. When Shell's BugreportReceiver receives the BUGREPORT_STARTED, it:
2.1 Issues a system notification so user can watch the
progresss (which is 0% initially).
2.2 Starts a service (BugreportProgressService) responsible for
polling the dumpstate progress (using system properties and the
pid) and updating the system notification.
3. As dumpstate progress, it updates the proper system property.
4. When dumpstate finishes, it sends a BUGREPORT_FINISHED event.
5. When Shell's BugreportReceiver receives the BUGREPORT_FINISHED, it:
5.1 Finishes the service if necessary.
5.2 Issues a system notification so user can share the bug report.
This CL handles the Shell changes only, the dumpstate changes will be
changed in a separate CL.
BUG: 25794470
Change-Id: Icbd0b42dd48e8db376b60544348b6818c6374338
services
If the SelectPrinterActivity is visible it shows different emptyState
depending on if there are print services available or not. Hence the
activity has to listen to changes to the list of enabled services.
This also fixes a small syncronsation problem if two observers are
registered for the enabled print services.
Bug: 25666802
Change-Id: I79af66f25f10e66347b48ce9bb99c1657b30a8dd
This is a follow up CL for 35d3f37bd5 [1],
which changed some method signatures of IInputMethodManager.
[1]: Ia1fe120af7d71495c5f3a4fc0ec6390efb8240ca
We need to update BridgeIInputMethodManager.java every time when we
change IInputMethodManager.
Bug: 25373872
Change-Id: I126dc4234f921039a9d29010ea411a0a7d2ef6c6
Two changes:
1. Allow to specify which user the call is inserted to
2. Store addForAllUsers in call, so that we do not need to copy every call
Change-Id: I8fc9e8e4f2e0bdb0049ca2914fdf8908f62b3eb2
This defers looking up the meta-data from the install call to when the
rest of the config is lazily initialized.
Change-Id: I008a86f885e158ebe06a2bacdc358cd217635d05
- Now, all task views will be bounded by the stack rect, and the
thumbnail bitmaps will be scaled accordingly to fit either by width
(when stacked) or to the view rect (when freeform)
- Fixing issue where the history button was not offset in freeform
- Tweaking thumbnail sizes of fullscreen screenshots
- Still requires changes to fix clipping to the correct aspect ratio in
freeform.
Change-Id: I678b87c2f06947d32f3bb7c60a35f28eb36b5a68
- Adding a notion of session to the stack. If the history is enabled,
the stack will now be constrained to show either tasks that were last
active in a window of time, or a minimum number of tasks.
- Giving the history button the full space above the stack so that it
looks more balanced.
Change-Id: If7b647349e8bb164ae86fd6dba3f7e974257eb5b
- Initial changes to show a history view within Overview (behind tuner
flag)
- Restoring the task view dim in the stack
Change-Id: I0503d11768736c86f3145942404391dfacd0ddd6
am: dd52b3db36
* commit 'dd52b3db3678dc0840b82f5406d445cea59d2b59':
ssl: make DistinguishedNameParser a package-private class in org.apache.http.conn.ssl
