In addition to the pixel format there is an extra
force opaque flag. We only update this on creation,
but we need to respond to changing SurfaceInsets forcing
an otherwise opaque surface to become translucent.
Bug: 27364161
Change-Id: I13c69d1271412a0bc71e936867c58d5c413ab56b
Wound up in a deadlock. We held mPackages lock and called the mount
service. This called into the AppOps service which tried to obtain
its lock. On another thread, we held the AppOps service lock which
called into PackageManager service and tried to take mPackages.
Ideally, we'd never hold an internal lock when calling externally.
In practice, that's not always fixable [for example, code change
would be too great to not hold the AppOps lock when calling into
the PackageManager service].
Bug: 28169075
Change-Id: If0a7f1361c7be9385b1f629f68ebc0556b08ab06
If a package targets a pre-release SDK [eg a letter version] it should not
be allowed to be upgraded by a release SDK [eg a number version]. If one
absolutely must upgrade to a release SDK, use the "--force-sdk" option
during install.
Bug: 28345311
Change-Id: Ic9fb209968e7c5da2c80c5ca4c0f44f5125f610a
When in FINISH_AFTER_VISIBLE mode, we need to check visibility of
both the current activity, and the activity to be resumed. If the
resumed activity is already visible, we should finish immediately.
We can't put it into stopping state and wait because there won't be
a window visible callback from the next activity.
bug: 28378359
Change-Id: Ib1fb44acfec33616da76f48102cc00b453e41914
When upgrading a package, we need to fill in the "origUsers" field
so that we can clone the installed state correctly. This was done
for child package, but never set for the parent package.
Also fix a bug where a secondary user requested a package to be
moved. Because that move was pushed onto a Handler, the calling
userId appeared to be the device owner instead of the user that
actually requested the move. (Later in the upgrade flow there is
code that force-installs the package for the requesting user.)
Bug: 26729822
Change-Id: I2d2a007c73558f29a3f8c1408ec373fce6e87761
For non-persistent debug settings, mDebugApp and mWaitForDebugger flags
will only be restored when we get attachApplication. If the process is
already running, we can't wait for debugger and there will be no
attachApplication calls coming.
We should leave the settings unmodified, otherwise after two such calls,
both mDebugApp and mOrigDebugApp will point to the same app, and the
debug settings can never be restored.
bug: 27931552
Change-Id: Id53e21bbe154f45bf2ca12bb5d7fd56279bae653
We used the system proterties as a shared memory mechanism
to propagate information to local settings caches when the
content has changed and the cache should be cleared. The
system properties are unfortunately updated asynchronously
leading to cases where clients may read stale data.
This change adds a simple int array data structure backed
by shared memory which guarantees individual values are
atomically read and updated without memory tear. Multi-
index opearations are not synchronized between each other.
The settings provider is using the new data structure to
propagate the settings generation which drives when caches
are purged.
We have a single memory array keeping the generation for
different settings tables per user. Since memory array is
not a compact data structure and the user space exceeds
the memory array size we use an in-memory map from keys
to indices in the memory array where the generation id of
a key is stored. A key is derived by the setting type in
the 4 most significant bits and the user id in the 28 least
significant bits.
The mapping from a key to an index is cleared if the user is
removed and the corresponding index in the memory arry is
reset to make it available for other users. The size of the
memory array is derived from the max user count that can be
created at the same time.
bug:18826179
Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
If an application(in /data) that other user installed it initially
is appended as system app later, owner user can not use the system app.
The reason this issue occurs is that the owner user's installed flag
is set false when the application was installed by other user
and the installed flag is not updated when the application is appended
as system app later.
So, we fix like as setting the installed flag to true
when the application is appended as system app.
Bug: 28183865
Change-Id: I0b4da5e0bb77fb3baf86d0453e6637a230b104ba
Usually wallpaper target gets updated when some wallpaper target window
finishes drawing. However in some cases, Recents app could be set to
visible again before its stopped. (Which could happen when we started
opening transition into some app with a saved surface, but the app draws
so slow so that when user pressed Recents button again, the app still
hasn't delivered first frame.) In this case, the surface is already
drawn and we won't get a finish drawing again. We need to make sure the
wallpaper target is updated.
bug: 27742244
Change-Id: I8ff53f15f95bae8a99a5a0fd11e24e0186dc3345
Fine tune the audio gain for Bluetooth Absolute Volume.
Use 50%, 70% and 85% for lowest volume steps 1, 2 and 3.
Thus the volume change sounds smoother, more linear.
When remote end tune volume out of mute, we should also
tune the audio gain for the lowest volume steps.
Bug: 26694114
Change-Id: I298a334a4b40ddb87495fda1935349bfce8b0537
Changes the policy for selecting packages which will be pre-verified
during post-OTA boot animation.
For Nx to Ny, an app is pre-verified if used in the foreground in the
last 7 days, or if its APK was loaded by other apps.
For M to N (or early N builds without detailed stats), an app is
pre-verified if it has any recorded use in the last 7 days.
Bug: 27902702
Bug: 27350503
Change-Id: I2b38daf017ecd0e5aa5ed596ed9351cffa03dbcb
Currently post-OTA verification will attempt to compile with
'verify-profile' but does not merge the profiles prior to calling
dex2oat. As a result, we may miss some or all classes that need
verification.
Bug: 27688727
Change-Id: I1aa93cad2686513594cb37f6d3d181ae5c718d1d
Now that it's long since been unused also delete the locking that was
introduced to make it possible.
Bug: 17733693
Bug: 24837343
Change-Id: Iee817a7c2e1d1dc9c080d3124d5986232dcda00f
When enabling a firewall rule that will deny networking to apps,
first close any sockets opened by those apps. Just dropping an
app's packets without closing its connections has the following
problems:
1. The app has no way to know this has happened until a network
timeout occurs.
2. The app's connections stay open, so the other end of the
connection (e.g., a server) might continue to retransmit
packets. These packets will wake up the kernel and cause
battery drain, but we cannot respond to them because packets
on those connections are dropped by the kernel (since the app
is blackholed). So the other end might keep retransmitting.
3. Even though we think the connections are still open, the
other end of the connection, or any intermediate NATs or
firewalls, might time out and close the connection (e.g., by
sending a RST). Because the app is blackholed, we have no way
of knowing that this has happened, so when the app is granted
network access again, these connections might just get stuck.
Bug: 27824851
Bug: 27867653
Change-Id: Iaaad1b26954fc5f1ba5c9ed8bdee039282f5e249
- When we get a collapse before the layout happened in SystemUI,
don't expand the panel after the layout.
- Don't reset waitingToShow when coming out of sleep. This will cause
win.isVisibleOrBehindKeyguardLw to return false and then occluded
state will change rapidly from true -> false -> true, leading to
flickering in SysUI.
Bug: 23898941
Change-Id: I2b941188de777086bb2b477f5bfc00cc0cd6abe0
This worked in pre-N because the only visible app was the app that can be
shown when the keyguard is hidden. That isn't the case in multi-window mode
where one of the apps can be shown when locked and the other doesn't have
the show when locked flag. Only hide the other app if the keyguard is shown.
Bug: 28368875
Change-Id: I5039098db74492fadf667fed24fc58448436681a
Cameraserver has been split from mediaserver, so need to use
its UID for determining whether to grant scheduling priority
change requests.
Bug: 28246165
Change-Id: I87b96e9fe0c0c38ec994d3d2aa131668d3d66986
Add code to wait for SycJobService to pass back an
instance of itself after boot before allowing syncs
to be scheduled.
Also removes unused constant MESSAGE_SYNC_EXPIRED.
Bug: 28380795
Change-Id: I616ba5c74578a81ff1e37ba4bd1fd937ce5c006d
