Calling Objects.hash with a byte[] will call the identity hashCode on
the byte[] and this doesn't agree with the use of Objects.deepEquals
in equals.
Bug caught by error prone.
Also, replaced usage of Objects.deepEquals(mServiceDataUuid, ...) with
Objects.equals(mServiceDataUuid, ...), because mServiceDataUuid
is an Object of type ParcelUuid.
Bug: 28585195
Change-Id: Id92734874339985fedafe1a28286a6a4dcd88d3b
It's a protected broadcast, so sending it directly from 'am' is
no longer an option. This is needed for CTS as well as being
generally useful during app development.
Bug 28406044
Change-Id: I101915a8c6f19454330a8db2079a75023c112582
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
This change refactores the mUidRules to use bitmasks, in preparation for
another change that will fix the issue.
It also fixes a minor bug that was preventing removed packages to be
removed from the whitelist.
BUG: 28521946
Change-Id: I9f0e1509a6192cad403f740c1cd76a6b7dab7d26
It is risky/complicated to try to put the activity showing on-top of
the lock screen in the right fullscreen configuration with the current
architecture. So, we just dismiss for now.
Bug: 28195260
Change-Id: I29a0350993ce8fe548d4a465b06d877cde151c78
This API was using a oneway aidl call, which meant that the
service was disabled some time after the method returned. That
confused tests that were turning a service off during tearDown
and then turning it back on again in setUp.
Bug: 28621277
Change-Id: I75984df0613bdbb1bc876e2a15caf59106027337
If there are no enrollment applications on the system, but someone still
makes a KeyphraseEnrollmentInfo and tries to print it, it would generate
a NPE on a map object. Instead of setting the map to null when we don't
find any enrollment applications, we can just set it to an empty map.
Bug:28622866
Change-Id: I023e6fd90effd3143c19817a0d6637a013bebc31
When relaunching an Activity, the DecorView and ViewRootImpl is re-used,
along with the IBinder activity token. This means that when we create
new resources, we end up just updating the base Activity resources.
However, we would set the configuration to the new requested override
config and then proceed to update existing Resources references, which
would return immediately due to the equality check for configuration
updates.
This change pushes the setting of the new override config to the
updateResourcesForActivity method, which will properly update Resources
references that are held in the re-used DecorView.
Bug:27915587
Change-Id: I113007a40fa464b8a234b073dcf851e16fee0177
You can't back up content in e.g. getNoBackupFilesDir() even if your
app explicitly tries to.
Bug 28321431
Change-Id: Ifa2a4bc518de03aba4c8809e60d8bb90fce767f8
Also increase the event buffer size to 100, and implement
it as a real ring buffer. And put that implementation in
a generic class for use in other places.
Change-Id: I06936984e2c253fb5f0eb5d15faf0019ec73d4e2
Fix this long-standing multi-threading issue in Bundle
when multiple threads are trying to read from a Bundle
and conflict to due unparceling.
There are two critical sections this protects: writing
the bundle in to a parcel (when it is doing this from
the bundle's already parcelled representation), and
unparcelling a bundle into its map of entries.
Change-Id: I5470002f090e63dd623a573da6c204d3b5b661f4
When the activity locally recreates itself, nothing
on the server side is able to prepare preserving windows,
or replacing windows. The activity was trying to defer
removing the old window, but it was just waiting
until the new one was created, not until it was drawn,
thus resulting in a flicker. It's easy to backpack on the
existing replacement infrastructure.
Bug: 28221875
Change-Id: I55fc4ca78e9e11809473fedd8b30b6a6350cf852
This bug was a corner case of stopping lying about
Configuration#keyboard when "Show software keyboard" is turned on, which
was done by my CL [1] in Android N development cycle.
Previous implementation
if (config.keyboard != Configuration.KEYBOARD_NOKEYS) {
had relied on the fact that the system was lying about config.keyboard,
which is no longer valid. We need to change the behavior of
InputMethodService#onShowInputRequested() depending on
Settings.Secure.SHOW_IME_WITH_HARD_KEYBOARD like we did for
InputMethodService#onEvaluateInputViewShown() in [1] to minimize the
impact on stopping lying about Configuration#keyboard.
[1]: Id4d332e3909590c68345e10e1f2e18650efb2eb7
7b739a802c
Bug: 28423439
Change-Id: I8a774cbf61ac706d8446be91b17bceee57a13656
In some cases it is possible for activity manager to request
a resumed activity to stop when it's visibility changes. This
is a valid transition, however we need to make sure to pause
the activity on the client side before stopping it so lifecycle
transition works as expected.
Bug: 28574036
Change-Id: I759b38bbd1c9c3bb0475759bcb638d8223fa504d
It's possible for a call to updateConfiguration() to happen in the middle
of performTraversals(), after the measure phase has happened, but before
the layout phase. During the configuration call, it's possible for views to
have requestLayout() called on them. This can result in the request flag
not getting cleared, because views that have had layout requested, but which
have not yet been measured, may not be told to layout.
The correct flow should be that any code path causing requestLayout() (which
could be anything that calls out to user/app code) should happen before the
measure phase (or cause a second measure to occur). For now, causing the second
measure to occur is a low-risk simple change that fixes the immediate problem.
Issue #28152259 Calling requestLayout from inside View.onConfigurationChanged can cause problems
Change-Id: I3b532eeacc3784d8d21193d01ddd7fa15ac0684e
