Save arbitrarily nested fragments across config changes as
nonconfiguration objects. This permits the use of retain-instance
child fragments as arbitrary opaque dependencies within other
fragments.
Change-Id: Ia6640b76cfcf7ec28ba252628957a0c14863e957
(cherry picked from commit 7466be66263d5ebffb786ea402d9ed6e36c254f0)
Updates the docs for addNewIncomingCall to mention that if the
PhoneAccountHandle representing a PhoneAccount is not registered or not
enabled, a SecurityException will be thrown (as of b/26864502). Also
notifies the user that PhoneAccounts are stored in DE storage
in registerPhoneAccount.
Bug: 26874536
Bug: 26780305
Change-Id: I2dae932cfa3404d7d5060dad840a75227793603e
Offer commitNow and commitNowAllowingStateLoss methods on Fragment for
use by encapsulated components using fragments as implementation
details. This can help prevent unexpected ordering side effects at the
app level when a call to a library method wants to commit and
immediately initialize a fragment as an implementation detail.
Note that this change still does not permit reentrant FragmentManager
operations. It is still an error to add/remove/change fragments in the
same FragmentManager while a fragment transaction is being executed.
Have the commonly used ViewPager adapters use commitNow instead of
executePendingTransactions.
Change-Id: Ia37a871234a287423063f0c2c3e4c93d69116cad
(cherry picked from commit f6b30662f87f7339d0d3946dcf71e930c2fead9b)
Have the new showContextMenuForChild(View, float, float) call through
to the old showContextMenuForChild(View) before recursing up to its
parent. This ensures that existing apps with custom views that
override the old method still get called as expected if they implement
custom behavior.
Unlike some other similar circumstances we aren't implementing this to
be bidirectional as the new behavior doesn't need to be triggered by
invoking the old. If the older method is invoked explicitly we will
still show old-style dialog context menus instead of the newer popup
style since we won't have a good place to visually anchor a popup.
Bug 26919262
Change-Id: Ie09f922d322b5a24789c7867820c4bc43824c385
(cherry picked from commit 759a4c54004af6ac9f42c9c42496a5eb73c461ff)
Add android.os.UpdateEngine and UpdateEngineCallback classes that
communicate with the update engine via binder APIs for A/B update.
Bug: 26695366
Change-Id: I2471858d28df5443bc0b56d9a20281ccebde4484
Showing the pid is useful in many cases, like when one bug report is finished
and another one is in progress.
BUG: 26906985
Change-Id: Ib8ae462c85246b99234f8dac63edb608d1eafeb0
The general theme of these changes is to always delay any action until
the printDocument finishes a command. This is done:
- Before callinng for into a different activity to select a name for the
PDF
- Before finishing
The second theme is to fix the canceling behavior of
RemotePrintDocument.AsyncCommand.
There are four bugs fixed in this review:
(1)
When the RemotePrintDocument.AsyncCommand is canceled it goes into the
"canceling" state. When it is canceled again it should stay in this
state. Before it went to "canceled" but the command was still running.
(see AsyncCommand#cancel()).
(2)
When finishing the PrintActivity in PrintActivity.doFinish() we cancel
the RemotePrintDocument. If there is a command still in progress (i.e.
isUpdating()) and it finished as canceled we used to call doFinish()
again and then try to double-clean up which lead to exceptions.
The new behavior is that is the PrintActivity is calling doFinish()
while a command is still in progress (i.e. isUpdating()) we delay the
cleanup until the command finishes. The command might finish as
canceled, completed or failed. Hence we have to call doFinish() in the
callbacks for all three cases.
(3)
When canceling there might have still been a nextCommand ready, hence
canceling does not stop execution of the RemotePrintDocument which could
lead to running commands while finshing.
(4)
When getting the location to store the PDF at a command might still be
in progress. This lead to half executed commands and caused issues once
we try to continue after the select-location-activity returns
Bug: 24713704
Bug: 24973884
Change-Id: Ied90fe8dc9bd6ea7f8b3e4ce4f922e477015568d
Add the means to protect FBE keys with a combination of an auth token
from Gatekeeper, and a hash of the password. Both of these must be
passed to unlock_user_key. Keys are created unprotected, and
change_user_key changes the way they are protected.
Bug: 22950892
Change-Id: Ie13bc6f82059ce941b0e664a5b60355e52b45f30
hotspot, color inversion, data saver, and work profiles should add
themselves when they first become applicable.
Also refactor the availability flow a little bit.
Change-Id: Iaed89059540a98fefd4d26ce69edc0dde987b992
Also, this is supposed to be a "machine-parseable" format,
but it's not versioned at all. Added a version field so we
can change the format in the future if desired.
Change-Id: I6aa8ea46e030def04dc10634d01557a044545a9b
libc++.so is no longer accessible to the app, so it must be
bundled in the app. This should get ApfTest passing again.
Change-Id: Ide004cb84f7f50feffb8f5acb46b7001dcffd208
When a system app requests "forceDeviceEncrypted" they expect their
default app storage to point at a consistent location regardless of
device FBE support. So when booting upgraded non-FBE devices, we
may need to migrate any data from CE to DE. Note that on non-FBE
devices these are just semantic locations with identical protection.
This migration *only* works for non-FBE devices; changing
forceDeviceEncrypted flags on an FBE device always requires a full
data wipe.
Bug: 26668510
Change-Id: Ic5dfeaaf2db26c385901a638ca8ec35eb3c52859
bug:17478770
This removes a lot of redundant property query code, and puts the
queries all in one place, so defining them automatically will be simpler
in the future.
Change-Id: I0428550e6081f07bc6554ffdf73b22284325abb8
If we're restoring after a background process death, the Parcelable
creator cache is cold, and since we're handing in a null ClassLoader
the best the platform can do is try the default ClassLoader which
knows nothing about the running app.
That's why ClassLoaderCreator exists, so use it to snag the relevant
ClassLoader and pass it along.
Bug: 26075620
Change-Id: I6fd977d6178dd0f5f9c465597f5806a08097ac7c
