When the ResolverActivity makes a filter after an intent is chosen,
either for remembering last used or an "always use" choice for the
user it doesn't consider the selector in the intent if present.
This means that when a resolver activity is launched for an intent
with a selector, the selector is used for resolving preferred
activities, and for populating the list, but when the same intent
is sent again it doesn't match the filter created by the previous
ResolverActivity.
This in turn means that the user will get another ResolverActivity
even if "Always Use" was chosen the last time.
Bug: 28129216
Change-Id: I29be7010e7c890caf9789673b3c3f821ba362761
Use ZygoteHooks code to mark zygote initialization to not be
allowed to create threads. This is helpful when new classes are
found to be used by apps but cannot be preloaded as they spawn
threads.
Bug: 27248115
Change-Id: I1dc3620d9e7d0054c672b993d89459fc4b353dfc
This leads to flickers, as we should not draw in a translucent way
if we didn't specify that our window is translucent, because the
renderer has some about translucency.
Instead, we should clip the backdrop content by the inverse of the
content clip rect, which is not yet implemented.
Bug: 28009524
Change-Id: Ia3f54fb83997ace863e78ff1cbe45cfb64f92f26
Symptom:
Calling startActivity() with an implicit intent,
ResolverActivity displays preferred activity candidates.
At first user selects one of them as "JUST ONCE".
And next, the last one is shown again on the top with "JUST ONCE" and
"ALWAYS".
But even if user selects another ones except top with "JUST ONCE".
Next time, the last one is not shown on the top.
Instead of that, first one still remain on the top.
It means that user can't select activities as "ALWAYS"
except first one.
Root cause:
The implicit intent has a URI but not MIME type.
In this case, Intent#resolveTypeIfNeeded returns "null".
So MIME type is not passed to PackageManagerService.
That's why this issue happens.
Change-Id: I87b6da9c5d8b47e071bbedf9f7d5f3ecea730875
Although DisplayNameWithDialect seems to return friendlier, more
"casual" names (e.g. "American English"), the result was inconsistent,
and (at times) debatable. And since this setting affects not only
the language of the translation, but a locale, names like "Flemish"
kind of lost the whole "locale / location" idea.
So we revert to use DisplayName for all but a few selected locales
(that we verified are better with the "dialect" form).
Bug: 27704583
Change-Id: I587081da1293cccac3cdabcd188a9b8160c233ea
This CL adds JavaDoc to clarify what previous CL [1] wanted to do.
No behavior change is intended in this CL.
[1]: I3694edd80be6dfe18b90360e24ae4d451b331928
d39ae85482
Bug: 25753404
Bug: 28103839
Change-Id: I246223c0856382d68323f22987b998cd1613e98c
1. Deduplicate the Tethering message numbers, and use MessageUtils
to convert them to strings.
2. Add a warning to NativeDaemonConnector when an unsolicited
event is more than 500ms late or takes more than 500ms to
process.
Bug: 27857665
Change-Id: I379aef9257027d1ccf30906e79c6389ef1f95420
When it's triggered, it happens with such frequency that it can DoS
the system server.
Bug: 28104329
Change-Id: I5c58e5f5bf4d88af2cb6215bcfddf35704e22eaa
Certain operations, such as clearing/destroying app data, or just
counting on-disk size, require us to know the CE storage directory
of a particular app. To facilitate these operations, offer a method
to get the inode of a CE directory, and accept that inode number
for later operations. Collect and store the inode number in
PackageUserState for future use when that user's CE storage is
still locked. This design means it's safe to clear/destroy app
data in both CE/DE storage at the same time.
Move most installd-related methods to a uniform calling convention
that accepts a single parent PackageParser.Package, and internally
fans out to handle all "leaf" packages under that parent.
In previous releases, we started installing apps using a new
directory-based layout, where all app code, unpacked native libraries,
and optimized code is bundled together. So now we only have a single
path to measure for code size. This fixes several outstanding bugs
that were causing sizes to be miscounted for apps supporting multiple
architectures.
Fix a subtle bug in PackageSettings that would cause "notLaunched"
to be parsed incorrectly.
Bug: 27828915, 27197819
Change-Id: Ia582cf3550553292bde4bb4313367111332913ec
This is a follow up CL to my previous CL [1], which added a new key
binding Meta+Space to rotate enabled IME subtypes. With this CL,
Shift+Meta+Space starts reverse-rotating enabled IME subtypes as
originally planed.
[1]: I4005692215edfcf8bed3e86b1e07000148f986f5
ae61f7118a
Bug: 25753404
Bug: 28103839
Change-Id: I3694edd80be6dfe18b90360e24ae4d451b331928
- Make minimal task size 220dp.
- Disable upper and lower targets if they result in less
than 220dp task size.
- If even the middle target doesn't allow 220dp task size,
disable entering split screen altogether.
Bug: 26451260
Change-Id: I06e358c9b3da0172c5def75cdadf975f87f9fa57
Since forcing it all the time has the potential of breaking
compatibility with apps, we don't want to do this.
Instead, we only force it if the app targets >= N.
We communicate this to window manager with
PRIVATE_FLAG_FORCE_DRAW_STATUS_BAR_BACKGROUND.
We introduced this for 2-up split-screen. If we have an app
that doesn't draw the status bar background by itself, we
just force the whole bar to be black.
The same applies for windows that used translucent status
bar - we also force the whole bar to be black
Bug: 27285627
Change-Id: I7f1ceaa364f8a4e851935f77aa5e8d913bf11791
Make sure to stop the thread when the window gets detached. When dismissing
the docked/fullscreen stack with the divider, we stop the activity while
we are still in resizing mode.
Bug: 28054032
Change-Id: I2d5d0ffaa9bc47e4d5252414b9a045beaebb7a69
Let apps invoking the system chooser specify components to filter out
such as themselves; this will prevent duplicate nonsensical UX where
it doesn't make sense for an app to share to itself.
Similarly, let apps provide their own Direct Share targets for when
they do want to let users share via their own internal services in the
same UI. These options can be used together.
Also fix a bug where a lingering binder reference from a remote
ChooserTargetService that hasn't been GC'd in the remote process could
keep an active reference to a ChooserActivity instance.
Bug 28073484
Change-Id: Ib613b1153b49dfedf79574b1af7c45379eceec24
Window manager factors in the surface insets when calculating the
right crop for a window surface. Without the surface insets been
updated and new param forwarded to window manager, the window crop
will not be the right size and the window drop shadow might not show.
Bug: 27364161
Change-Id: Ieefeb8435543f3137672a065269cdeefca371111
ag/898112 added passing the window title to accessibility. To do that,
it also updated copy of the title in WindowManager.LayoutParams. That
was a behavior change, and the change broke cts tests that enforce that
the title in LayoutParams matches its expected format.
This change restores the previous behavior and adds a separate field to
LayoutParams to old an up-to-date title to pass to accessibility.
Bug: 28002185
Change-Id: Ia5b549113600b7c4fcc80b76c3f3a944dddaf483
The check for sequence numbers is triggering when ProcessStats
is accessed after being read from a parcel. Turn off the check
for now.
Bug: 27045736
Bug: 27960286
Bug: 28039193
Bug: 28021719
Bug: 27960286
Change-Id: I7438441135fd1e9ce01350034262451309165525
When work profile is turned off, attempts to start work app activity is
intercepted and redirected to an information dialog, which gives the
option to turn work profile back on. When the user does turn it back on,
the original activity should be relaunched.
Bug: 27740167
Change-Id: I4c9d5bc949499bdb5d9f2394e13e670a48d43629
Changes:
(1) When unified work challenge is enabled and screen lock is secure
- Store work profile secure key in primary profile
- When primary user keystore unlocked, unlock work profile keystore
- When primary user change lock to none, remove work secure key
(2) When unified work challenge is enabled but screen lock is not secure
- When screen lock changes to secure, store work secure key in primary
(3) When user changes work challenge from unified to separated
- Remove work secure key in primary
(4) When user changes work challenge from separate to unified
- Do (1) and (2)
Bug: 27460698
Change-Id: I8f77bde5dc6b8e59c90256e75c5990100e93366b
There are a handful of looper threads in the system_process that
are shared by dozens of different internal services. To help track
down what these operations are, tag the processing of each message
with a string that tries describing where it originated from: the
class name of the Handler, and the message number or class name of the
Runnable.
Bug: 28046299
Change-Id: I409ec43fea8daaae4fd70df05d4fed929a7249ae
Ensure we calculate based on the actual menu items in a particular menu
or submenu, not based on whether the parent menu had icon spacing
enabled.
Bug: 28026351
Change-Id: Ie6e56eb142f0b82de38bf39ee848ddd26df2bf1c
- Encode '\u000' - '\u001F', so KXmlParser can read them properly.
Otherwise KXmlParser will ignore CRs/LFs in attributes, and CRs
in text.
- Originally FastXmlSerializer would throw if a string contains
dangling surrogate pairs. Now we REPLACE them with.
Bug 27792649
Change-Id: I10c547dad2475b68f60e9e8208d9a3eae8e20063
We should be calling close(false), not dismiss(), when the submenu is
opened.
This change brings the code closer to what it was before the prior
change to StandardMenuPopup, but preserves the ondismiss behavior we
want for popup menus. The net change so far is that StandardMenuPopup,
not MenuBuilder#performItemAction, handles closing the top level menu
when a submenu is opened. But nonetheless, the onDismiss is not called
when a submenu is opened; only when an actual real "dismiss" occurs.
Bug: 28001958
Change-Id: Ia0f89f8fd4bc5494f6a048c993792adfe42d88ec
