We allowed activities to move to any stack, but that's too much
freedom. Instead we only allow them to move from freeform stack to a
fullscreen stack.
Change-Id: I04de9bbf18cf4431d7bd34d6c727de82802661ef
When SpannableStringBuilder.replace is called with a source text that
contains a span with SPAN_PARAGRAPH flag, the code tries to retain the
spans. However when the paragraph boundary constraint is not satisfied,
setSpan method throws an exception. Updated the rule as: if the source
text has a span with SPAN_PARAGRAPH flag check if it can be copied into
the target. If not, discard the span. Also updated the JavaDoc for
Spanned and Editable.
Bug: 22521443
Change-Id: Ie8541e00bfdf5b8b0115ad7b26cb9f83a6a3ee55
The change has all the platform changes required to support
modifications in the navbar dimensions and custom icons in car mode.
The UX is not frozen yet, but have placeholder resources provided
by android auto UX engineers.
The change assumes that the car mode configuration is known to the
WindowManagerService and uses its current ui mode to request the
latest from the policy (PhoneWindowManager.java). The change is
modeled on the way rotation is handled, where the Policy knows the
different view attributes for uiMode and just returns back the
window sizes based on the current uiMode requested. The policy does
know the current uiMode, but the order of when that changes is not
deterministic [from logs it does happen before any request to update
UI occurs, but guess that could change].
Bug: 25996809
Change-Id: Ia46cbe5096382d26c9eb8ec74cf59a059b767edb
After receiving android.intent.action.REMOTE_BUGREPORT_FINISHED
in newly created RemoteBugreportReceiver, Shell will generate URI
to the bugreport zip file and send the broadcast
android.intent.action.REMOTE_BUGREPORT_DISPATCH.
Bug: 26152603
Change-Id: I058d626e021b488c9347b45467a4e3505134e79c
When booting the device in core-only mode we're running over a tmpfs
and only a small handful of apps are actually available. Don't
bother looking for verifiers or installers, since we probably won't
find them.
Bug: 26438767
Change-Id: Ia4c4a6e71007b01c4aaa273c2e0197b5cd021262
If they don't have code, give the developer a somewhat helpful error
message instead of later falling into a weird classpath failure.
Change-Id: Iebda10173ff99943cbbd71127ae24aa455b709f4
The original intention for forcing ninepatches to be encoded as
RGBA (with alpha) was to avoid the possibility of the decoder
producing 565 output.
565 output is bad for ninepatches because dithering tiny images
that we intend to scale later leads to bad results. I would
argue that, since the new BitmapFactory does not dither, we might
now be ok to allow 565 decodes for ninepatches. However, we
will maintain the old behavior by disabling 565 decodes for
ninepatch.
There are two changes to PNG encodings:
(1) Allows ninepatch images to be encoded in any mode. Forcing
them to RGBA makes things awkward for the decoder. Currently,
BitmapFactory's png decoder checks every pixel for alpha.
That way, RGBA images that are actually opaque can be marked
as opaque, in order to optimize drawing. We want to remove
this complexity from the decoder.
(2) Make sure ninepatch chunks are stored in the png header. That
way we know immediately that the png is a ninepatch, and can
refuse to decode to 565 (if we feel this is best).
Change-Id: I724f5dbefb1be7b412f9b362dff83cbc0603f0bf
Specify in the javadocs the behavior when the message is formed
from whitespaces only. It is not obvious.
Bug: 26313904
Change-Id: I51d5722f090a0780a65f20395bee4fc40f9eb446
