The problem was that the ResolverActivity filters some activities
out of the list it shows, but it uses that display list as the
list of components the preference is set against when ultimately
setting it on the package manager... but that filtered list is *not*
the right component set, since it is not the same as the package
manager's view on it.
The fix here is to retain the original set of matching components
and use that when setting the preferred activity. Note that this
does mean that in very unusual cases where filtering is happeing
(such as one of the activities not being exported but being seen
as a possible completion from another app), then you will be setting
the preference for the complete set. Ultimately we probably need
to have the package manager apply these filtering rules up-front so
this is all consistent, but this is a very rare case so not that
important.
And then most of the change here is just improving the debug
output for intent resolution.
Change-Id: Ie35ac2c05a45946439951bbf41433c8b7de79c05
1. The fused printers provider was dropping on the floor received printers
if it was not active. It is in fact a loaded and if not active it should compute
the printers and not deliver them until activated. This fixes an issue where
opening the print dialog, then enabling a print service results in the printers
reported by the service not showing up in the print dialog.
2. Printer discovery session was created twice which leads to incorrect behavior
as the pint system is designed around the contract that there is a single
printer discovery session per service at a time. This was possible due to an
incorrect initialization of a member variable resulting in double session creation
when the print service is connected.
3. When a print service is enabled during discovery we did not use the correct
condition to start printer discovery resulting in starting it all the time even if
not needed. Also if some of the printers that had to be tracked are reported
by the service just enabled (typically historical printers) we did not ask the
service to start tracking them.
4. Removed some logging.
bug:10903343
Change-Id: I46c049471a4b099fc668df3aee2aaedc8d7786ac
Various artifacts across apps were coming from ActionBar's use of
the new transitions framework. Disabling transitions for now to get
things back to a more stable state.
Also, fixed some related bugs in transitions themselves, including
a change in TextChange to account for text selection, which was causing
errors in Keep's SearchView.
Issue #10860557 TextChange animator may old stale value
Issue #10819685 sometimes icons are lighter
Issue #10750525 Share and Settings icons overlap when stopping slideshow
Issue #10839551 Sometimes the search text box is right-aligned in Keep
Issue #10727484 Cursor incorrectly positioned after entering first letter during search action in keep app
Change-Id: Iad7cbf3297e18018308b8148b3519b032e63dace
Uses new column to mark writability. Also filter file selection in
create mode to only allow writable files.
Bug: 10667164, 10893268
Change-Id: I90f74efbb7ac634fbdb3cc02a904a96a434d3605
ParcelFileDescriptors now carry an optional socket fd to communicate
close events. So, make sure that the correct creator is called when
reconstructing parceled PFDs.
Bug: 10759966
Change-Id: Ic6b9ffb8cb7af5f3a12440def595f74682231866
Driven by a new framework config bool. Tested on all layouts,
but disabled by default. Can be enabled with a config overlay.
(Sliding/MultiPane)ChallengeLayout have custom measure/layout
logic that peeks at the root view's padding (!). So we must keep
the root view's padding = system window insets. However, we need
the scrims + the fullscreen camera widget preview to use the entire
display size if the bars are transparent.
So the approach is to maintain the root view's
(KeyguardViewManager$ViewManagerHost) padding as before via
setFitsSystemWindows(true) but allow non KeyguardHostViews to
extend into the padding if bars are transparent via a custom
measure/draw on the root view.
KeyguardHostView background + challege scrims moved up to the
root view.
Also:
- Remove logspam line for fixed bug.
- Fix status bar staying opaque on interaction on secure keyguard.
Known issues:
- Nav bar blip dismissing global actions, keyguard app widget picker
bars are opaque. Both will use the new inherit flag once it exists.
- Emergency dialer layout dance, will be fixed in the phone project.
Bug:10606085
Change-Id: I2648b4ee9a54a67324ce9dcbab976ad4da4bbcfa
Changed public constants from integers to strings. Internally
everything is still integers, since we want that more efficient
representation for most things.
Changed the Callback interface to OnOpChangedListener. We also
have a private versin that again takes an int, and tricks to
make both work.
Reworked the class documentation to be appropriate to the SDK
(as much as it can be); most of the existing documentation is
moved to the private implementation. Also added documentation
of the MODE constants.
Change-Id: I4f7e73cc99fe66beff9194e960e072e2aa9458f8
Internally the API uses the same code path as SkTypeface::CreateFromName which
returns NULL if the requested style is not supported by the existing family.
However, the existing Java API expects that we return the default font in the
requested style so this CL ensures that we do.
bug: 10860066
Change-Id: Ide3a0cc24015e97fa35aef283b42e7d7d11edd9c
When a file already exists on disk, try adding a counter suffix to
make a unique name. Move services near top of roots list, just below
recents. Remove "Documents" root.
Increase number of recents allowed from single provider, and add more
logging to diagnose wedged loaders.
When launching GET_CONTENT apps, wait for successful result before
relaying result; canceled requests now return to DocumentsUI.
Add CloseGuard to ContentProviderClients, since leaked instances can
keep the remote process alive.
Fix UI bug around trailing breadcrumbs. Fix bug that dropped Recents
from roots list. Add up action to Settings activity. Give our
activity a default icon while waiting for async roots to load.
Bug: 10818683, 10819461, 10819461, 10819196, 10860199
Change-Id: I7b9e26b1cf8353dd3175458b23da2b4bda6c5831
Previously I was calling setIsConnectedToProvisioningNetwork(false) always,
but all MDST's receive every broadcast. Thus we could over write an MDST's
mNetworkInfo.mIsConnectedToProvisioningNetwork to false, unless the MDST
that was set to true was last, i.e the code was order dependent.
If the provisioning networks value was false instead of true
when handleMobileProvisioningAction was called we wouldn't invoke
mdst.enableMobileProvisioning because network info would be null.
Thus the provisioning network would never transition to CONNECTED and
a default route wouldn't get setup and the browser couldn't access the
website.
Now setIsConnectedToProvisioningNetwork is only set to false when the
apnType matches and we won't indiscriminately change it and are not
order dependent.
Bug: 10853805
Change-Id: I68a4f9bdf5dc18d90f4cdef7a60811f57be67261
