Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
1. Check that dual-use text/emoji character that default to text
style are available in a font before the emoji font. (Exceptions are
Unicode 7.0 characters that Noto Symbols doesn't support yet and four
odd characters that should be added to the Noto Symbols subset.)
2. Remove previous workaround for default emoji-style characters that
were in the Noto CJK fonts, since they are now subsetted out from
Noto CJK.
Bug: 26113320
Bug: 26187231
Change-Id: Ib9ea2f4f7e6ca0cd8d291f1dc3d7ee5053d4928e
1. Check that all emoji characters are supported in emoji fonts.
2. Check that no default-emoji characters are included in any font
that can get a higher score then the color emoji font, either by
being before it or by having a language/script assigned.
Bug: 26187231
Change-Id: Ic76bf59f1c6f9d2d290b1b64128d725ae08dcb5c
Summary:
This CL introduces a unified mechanism to deal with the situation
where the application directly implements InputConnection but some of
methods are not implemented. Note that there should be zero overhead
when the application extends BaseInputConnection or
InputConnectionWrapper.
Background:
When ever we add a new method to InputConnection, there has been a
risk that existing applications that directly implement
InputConnection can get java.lang.AbstractMethodError exception at
runtime, because older SDKs do not require the application developer
to implement the methods that are newly added in later SDKs. Because
of this we strongly discouraged developers to directly implement
InputConnection interface, and encouraged them to subclass
BaseInputConnection or InputConnectionWrapper instead. That said, as
requested in Bug 26945674, there is a certain demand to be able to
implement InputConnection without depending on BaseInputConnection.
The goal of this CL is to provide a reliable and sustainable solution
to above missing method scenario in InputConnection.
One of the reasons why dealing with missing InputConnection methods is
so difficult is that what InputMethodService receives to communicate
with the target application is actually a proxy class
com.android.internal.view.InputConnectionWrapper
that runs in the IME process and immediately returns true for most of
methods in InputConnection such as #commitText() and
#finishComposingText(). Because of this asynchronous nature, it is
too late to change the actual return value that the IME receives when
the application receives those one-way asynchronous IPC calls.
Solution:
To handle those cases, this CL checks the availability of
InputConnection methods that did not exist in the initial release
before the target application calls startInput(), and let the
application to send its availability bits to IMMS so that
InputConnectionWrapper running in the IME process can be initialized
with such availability bits. Note that we do know that
BaseInputConnection and its subclasses support all the InputConnection
methods, hence for most of applications we can just assume that all
the methods are available without reflection.
With such availability bits, InputConnectionWrapper is now able to
gracefully return failure code to the IME because the availability of
those methods is immutable, except for a tricky case where the
application relies on a proxy object that dynamically changes the
dispatch target.
Here is the list of APIs that we start checking the availability in
this CL.
[API Level 9+]
- InputConnection#getSelectedText(int)
- InputConnection#setComposingRegion(int, int)
[API Level 11+]
- InputConnection#commitCorrection(CorrectionInfo)
[API Level 21+]
- InputConnection#requestCursorUpdates(int)}
[API Level 24+]
- InputConnection#deleteSurroundingTextInCodePoints(int, int)
- InputConnection#getHandler()
Ideas alternatively considered: Default methods in InputConnection
We once considered having default methods in InputConnection but
abandoned this idea because it does not directly solve the problem
about how to tell the that the API does not take effect.
Also having default methods would make it difficult for application
developers to be aware of newly added methods in InputConnection.
Bug: 27407234
Bug: 27642734
Bug: 27650039
Change-Id: I3c58fadd924fad72cb984f0c23d3099fd0295c64
Hides the wallpaper when it's not needed and fixes
the unlock animation to not unnecessairly show the
wallpaper if neither the Keyguard nor the underlying
app need it.
Also fixes a bug where the enter animation had a background
set, which led to uglyness when no wallpaper is involved.
Bug: 27533740
Change-Id: I667c6f7ca6c0e1ff7e9f793c6ddc13f6da8387b1
Layoutlib only disposes the bitmap and doesn't recycle them. This causes
a double deallocation that triggers an assertion.
This change makes Bitmaps to be only freed when the finalizer is called.
Bug: http://b.android.com/203129
Change-Id: Ieabc1443544cfd2b4bf8ba9c8f9a4df8dd6e8220
Various tests have been added:
1. Availability of hyphens: Make sure that every font used for
rendering a language that is automatically hyphenated includes either
of Unicode hyphen characters U+2010 HYPHEN or U+002D HYPHEN-MINUS.
2. Range of values: Make sure that styles, weights, and styles belong
to certain limited sets.
Bug: 26187231
Bug: 21570828
Bug: 21815394
Change-Id: Ia63d63cc8da4f2d6bc81fe5619ccac6cfcd9a54e
Adds tap affordance that moves all tasks of the docked
stack into the fullscreen stack as well as moves the top task
of the fullscreen stack into the docked stack.
Also make sure not to trigger focus switch when tapping the divider
handle. For that, add a method so SysUI can specify the touchable
region which then gets excludes for the focus switch touch region.
Bug: 27358134
Change-Id: I34f39c53cacc0b9c00f87a792b88c3f64a5f61e1
file::mkdirs would try to extract the first part of the
path '/path' which would be the empty string ''. Mkdir would
fail creating the empty string directory.
Change-Id: Ice8ba92135f145f52f3663499a2c49eebe797328
This is a very hacky fix to make layoutlib work with the latest support
lib. Inject a couple of fields in android.content.res.Resources to
allow using most of the earlier code as is.
Bug: 27403642
Bug: http://b.android.com/201934
Change-Id: Ia96a1b4642a1907a77d9ca7a2392f78809b92e38
Android static libraries are like APKs but they contain much more debugging
and source information. We need to treat them differently in 3 ways:
1) When building a static library, we skip things like ID assignment and
product/config stripping. Source information is emitted as well.
2) When building a static library and linking against another
static library, we don't want to merge, we want to simply reference.
3) When building an app that uses static libraries, we want to merge
the static library under the same package with or without mangling.
Bug:25958912
Change-Id: I425e032857936a3e83173c1edc2a6cdc6020b842
Do not merge because the resource implementation has changed in N and
the change is no longer valid there.
This is a very hacky fix to make layoutlib work with the latest support
lib. Inject a couple of fields in android.content.res.Resources to
allow using most of the earlier code as is.
Bug: 27403642
Bug: http://b.android.com/201934
Change-Id: I186cad32b1b4de64164fbad937d989e0110c6976
It is possible for an activity to be in the stopped state without
setting it's visiblility to false in window manager.
For example, the home acitivty behind the lock screen. Since the
lock screen isn't an activity it doesn't affect the visiblity set
of the home activity, so AM doesn't tell WM to hide the app token.
However, AM uses another channel to detect that the device is locked
and moves the activity into stopped state. WM on the other hand also
detects that the device is locked and hides the window surfaces of
all windows behind the lock screen. So, at this point AM has also
told WM that the activity is stopped. Once you unlock the screen
AM resumes the activity but doesn't report any visiblility changes to WM
since it's internal state didn't change. So, if you go from the home
activity to another app the home activity window will be destroyed
before the activity is stopped because mAppStopped is set to true.
We now set mAppStopped to false when the activity is resumed.
Bug: 27286867
Change-Id: Ic75456d30abd582fa44f932f5aeeb449950157ee
Previously, a bit was kept to find if the script of a locale was
explicitly "provided" in a resource. This was not backward
compatible, and failed in some edge cases when the package was
created with older versions of AAPT that did not set the bit.
The cases would happen when the old resource had an explicit script
specified in its locale, but since the "provided" bit was not set in
the package, we would assume that the script was computed by us.
This CL replaces the "provided" bit with a "computed" bit, so the
default value of the bit (set to "false" for old packages) would be
correct.
Bug: 27156990
Change-Id: I99e7f1ad8f70c90e25ab3640ed34cc1a6f8d1d64
It allows badging an image regardless of of the user (no
user id parameter). The styling for managed users is applied.
This is useful for new cases where the existing functions
wouldn't badge the icon, but we need it.
Bug: 25192539
Change-Id: I2fd2f226f626fb2e6cda1cfe072013350e12b41c
This tests the bugfix in StubMethodAdapter made in the change with id
I098996e43e330e995d33f12df1c16355bbc02f0f (commit 491523d)
Change-Id: I1ac897a49071dd9558bdc6b8abec29df913a6047
They are only used on host and are one of the few places
in the build that use LOCAL_JACK_ENABLED := disabled.
Bug: 27218410
Change-Id: Ida6e649ad33decc743e8190a86486e7c4f8e5c88
Most of the VectorDrawable implementation has been moved to native code.
This CL implements most of the required functionality that existed in
Marshmallow.
Change-Id: I009bcd5c166f2bfa0795d2718fabab4a549eba9f
