The APIs are createBond, setPin, setPairingConfirmation
The intent is ACTION_PAIRING_REQUEST
bug 11101076
Change-Id: I3a314efd973b3ce078ab5347159c336f222d9f15
Also disables all setting of PAC networks through the internal AsyncChannel
methods. PAC can only be saved through addOrUpdateNetwork for permission
checks.
Bug: 11316946
Change-Id: I51016b578080c342a5e5d536ea9a3fdd4fe16644
Fix CountryDetector NPE by calling CallerInfo.getCurrentCountryIso() which
checks for potential nulls.
Bug:11291034
Change-Id: I0a4412c432551c64ec30652d69636442653ee337
In this case:
1. Privileged system app FOO is overlain by an installed update,
2. FOO was replaced during an OTA,
3. The new in-system FOO introduced new privileged permission requests
that had not been requested by the original FOO,
4. the update version of FOO still had a higher version code than
the new FOO on the system disk, and
5. the update version of FOO had been requesting these same (newly-
added-to-system-apk) permissions all along;
then the newly-added privileged permission requests were incorrectly being
refused. FOO should be able to use any privileged permission used by the
APK sited on the system disk; but instead, it was only being granted the
permissions used by the *original* version of FOO, even though the system
FOO now attempted to use them.
Still with me?
The fix is to (a) properly track privileged-install state when processing
known-to-be-hidden system packages, and (b) to tie the semantics of the
permission grant more explicitly to that evaluated state, rather than
using the prior (rather fragile) fixed-up privilege calculation applied
to the overlain apk's parse records.
Bug 11271490
Change-Id: Id8a45d667e52f3b5d18109e3620d5865f85bb9c9
Bug 11291911
These deleted classes were previously public APIs and so need to remain
in the build (but hidden) in order to keep existing apps working.
(Partially reverts Change-Id: I02549a71104b35d86d99058c71f43e054730ec7d)
Change-Id: I28e53b056f41e66645136f5e18fba2ff55a65fe5
Although the IME windows are now allowed to extend into
the nav bar, some IMEs were making assumptions about
computed insets based on the height of the content view.
So our navigation bar view (opaque view blocking the nav bar
area to avoid the island effect when transparent) needs to live
above the content view in the hierarchy, making the content view
the same height as it was before.
A surgical spot to put the guard view is up at the root view
(PhoneWindow.DecorView). fitSystemWindows is always called since
this view is not recreated, and the layout is stable: waiting until
the IME is attached to the window is too late to add a guard view.
This is above the screen_* layouts, so will work without having to
touch all of them. And it only affects windows of TYPE_INPUT_METHOD.
Bug:11237795
Change-Id: I6a93f30aec83f1cecfb854073046cbc87ab4aa66
1. For an app to print it creates a PrintDocumentAdapter implementation
which is passed to the print dialog activity. If the activity that
created the adapter is destroyed then the adapter, which may rely on
the activity state, may be in an invalid state. For example, an app
creates an adapter and calls print resuting in the app activity and
the print dialog activity being stacked. Now the user rotates the
device which triggers the recreating of the activity stack (assume the
app does not handle rotation). The recreated print dialog activity
receives the intent that originally created it with containing the
adapter that was constructed in the context of the old, now destroyed,
app activity instance.
To handle this we are limiting an app to be able to print only from
and activity and when this activity is destroyed we mark the adapter
as invalid which will result in hiding the print dialog activity. Note
that if the app process is killed we already handle this in the print
dialog activiy by registering a death recipient on the adapter binder.
2. In the PrintManager.PrintDocumentAdapterDelegate some of the state is
accessed only on the main thread and some from miltiple threads. The
code was trying to avoid locking for state that is not accessed by
multiple threads but this is error prone and the benefit does not
justify the complexity and added fragility. Now grabbing a lock all
the time.
3. The PrintJobConfigActivity waits for it to bind to the print spooler
service before instantiating its print controller and editor. However,
these can be accessed by invoking some of the activity cycle callbacks.
This change is adding null checks for the case where the activity
callbacks are called before the binding to the spooler is completed.
bug:11242661
Change-Id: Id906b3170e4f0a0553772dfa62686f06fdca0eaf
