Instead we install preloaded-classes as a standalone configuration file
/system/etc/preloaded-classes, so we can configure different file per product.
Bug: 18305157
Change-Id: I22f1a1dd44f90268d02532bf18405768523c0b1b
In practice, recognize that the current transport state may not yet
incorporate a valid restore data stream object, so don't go making
assumptions that it's usable / closeable / etc.
Bug 18379004
Change-Id: I221e04b5b83438e37455e025d67f412d3abb8c50
It is disabled dead code already and not useful anymore
with the new caching in LockSettingsService.
Bug: 18163444
Change-Id: Icc184e923e0fbeab31ed128336c01f835b24c6f2
Add a special case for situations where we have some activities
that are matching a URI host/path, so that these are ordered
above others. This only happens when dealing with http or https
intents, for ordering native apps above the browser.
Change-Id: I21f3361229bc7a1ebefda66373d31b6b1fd19973
This expands the use of EXTRA_REFERRER to be relevant anywhere,
allowing apps to supply referrer information if they want. However,
if they don't explicitly supply it, then the platform now keeps
track of package names that go with Intents when delivering them
to apps, which it can be returned as the default value.
The new method Activity.getReferrer() is used to retrieve this
referrer information. It knows about EXTRA_REFERRER, it can return
the default package name tracked internally, and it also can return
a new EXTRA_REFERRER_NAME if that exists. The latter is needed
because we can't use EXTRA_REFERRER in some cases since it is a Uri,
and things like #Intent; URI extras can only generate primitive type
extras. We really need to support this syntax for referrers, so we
need to have this additional extra field as an option.
When a referrer is to a native app, we are adopting the android-app
scheme. Since we are doing this, Intent's URI creation and parsing
now supports this scheme, and we improve its syntax to be able to build
intents with custom actions and stuff, instead of being all hung up
on custom schemes.
While doing this, fixed a problem when parsing both intent: and new
android-app: schemes with a selector portion, where we were not
respecting any scheme that was specified.
Change-Id: I06e55221e21a8156c1d6ac755a254fea386917a2
Removes lock-to-app request dialog from the AM.
Added a showScreenPinningRequest to IStatusBar to handle the
flow from app requesting lock task to showing the dialog.
This CL also allows startLockTaskOnCurrent (system|signature) to
start lock task directly. (Note: this is the less locked version
that always allows exit through back + recents)
Bug: 16957435
Change-Id: I284918dd5989de6cb2767c2a717529eb5e9c6db4
This is a follow up CL for recent attempt to minimize
the number of default enabled IMEs.
- part1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
- part2: Ife93d909fb8a24471c425c903e2b7048826e17a3
- part3: I6571d464a46453934f0a8f5e79018a67a9a3c845
It turned out that the changes made in part2 and part3 are
a bit overkill, and users will see no software keyboards
in some particular situations. The problem we missed in
the previous CLs is the fact that
InputMethodInfo#isDefault is indeed a locale-dependent
value, hence it may vary depending on the system locale.
Existing unittests also failed to abstract such
locale-dependent nature.
In order to addresses that regression, the selection logic
is a bit widely reorganized in this CL. Now the logic is
implemented as a series of fallback rules.
Also, unit tests are updated to be able to 1) test the
order of the enabled IMEs, and 2) emulate the
locale-dependent behavior of InputMethodInfo#isDefault
to enrich test cases.
BUG: 17347871
BUG: 18192576
Change-Id: I871ccda787eb0f1099ba3574356c1da4b33681f3
If a chooser intent is fired:
If the user picks "work" or "personal apps":
send a chooser intent to the other profile instead of sending a normal intent.
Also using a userId instead of a userHandle for the target user.
BUG:16514027
Change-Id: I2e45cd57ad72e9b7280e772b31fc10938642ba59
- Don't print every little native process.
- Print in different sections, so if one is too long we don't get the
rest truncated in the log.
- Include other info from meminfo -- ksm and free/used/lost summary.
Change-Id: Iea4ec3860212667e195d2b60b3ded23bfec78436
Let the user swipe the intent resolver UI off of the screen to get rid
of it. So satisfying!
Also fix a bug where transitioning between touching the area outside
of the drawer to the drawer itself would misbehave or otherwise
dismiss when it shouldn't.
Bug 18026675
Change-Id: I456cc22b9575dc4c65e45154dc81201fe2045adc
Existing hidden methods allow activities to be notified when their
windows have completed animating in. This change adds that capability
to system windows using a ViewTreeObserver callback since system
windows lack an activity token.
The first subsystem to use this is the UserSwitchingDialog which was
previously using a 250 msec timeout to dismiss the dialog. That
deadline was often missed leaving the user with no dialog on the
screen during the transition.
Fixes bug 16661752.
Change-Id: I70789e0d9c07112f275e76fb82850926305f290d
Tracks which window caused the disable flags
instead of just blaming PhoneWindowManager.
Bug: 17830264
Change-Id: If6c957120bb2ee8e0083f80e35c71eb21b8672b6
Also adds IntArray, which is like LongArray for integers, and prevents
the AM/PM label text in the time picker header from wrapping.
BUG: 17468036
Change-Id: I7120089885709f23e20368927e4b3ed9db2e5393
Just kidding we do want this to work like it used to.
This reverts commit e354a9e4da56da45d7035e1e93301554c5faf32e.
Change-Id: Ia51050a93e25c1ad16144b0da3f6178a98ad971a
Introduce notification_action_click logtag that is logged whenever
the user clicks any notification button. For standard templates, we
also log the index of the pressed action button.
Bug: 18064190
Change-Id: Icb07795ff711729d16bde0b7e03d13c2f466779c
