Bug #9425270
A better solution would be to use glCopyTexImage2D whenever possible but
this change would be a little more dangerous.
Change-Id: Ib1aaceda39d838716285ef97f356721416822dbb
Bug #9425270
When a TextureView is detached from its window and immediately
re-attached, the display list is not destroyed but reused as is.
TextureView will however destroy the layer and surface texture
reference by the display list.
The solution is to force TextureView to invalidate its display
list on re-attach if it previously had a surface/layer pair.
Change-Id: I475096ffa7e5709155c4c943bf1bfaaaedbd4a1d
- Sending a broadcast indicating when scan requests could be serviced so that
apps don't request scans we won't do anything with.
- Fix our batt stats accounting so we only count it if we send the request to
the driver.
bug: 8868201
bug: 9496690
Change-Id: I64a4f1c294c848ac64c50d8854ed4a6a1a47f603
Initially the current user in the accessibility manager service is the
owner. This is correct since the system should be able to respond to
queries immediately and their result depends on the current user. However,
the system is calling the user switch callback with the current user
which is the same as the one we initialized with. Switching the user
causes clearing state for the old user winch is in case the current
one. Hence, we are losing state for the current user. This behavior was
masked from the fact that accidentally no events in the system were
fired before the first use user switch call.
repo Losing current user state puts the manager service in an inconsistent
state and it binds to accessibility services more than once. As a result
the accessibility layer starts to misbehave rendering the device useless
to a blind user.
Now we are ignoring user switch callbacks if the new user is the same
as the current one. Since we can no longer initialize at the first user
switch, this change adds explicit system ready method called from
the system server at the right moment.
bug:9496697
Change-Id: Icb39e929ea44e6c0360aba7ddc12f941ca2c9f98
This is WRONG WRONG WRONG but certain apps rely on it to
poke the LED and so forth. In a future release this will
stop working.
Bug: 8623399
Change-Id: I49bb8ccc6891b1398ceec94c64d6c3a510ad1c38
This was a regression caused by a recent change to use String8
instead of char*. We missed the implicit null check here.
Bug: 9377604
Change-Id: I7eff138096622c47b5d45678010373dc82138384
Previously CarrierProvisioning toggle airplane mode, but now that's
available only by the system.
Bug: 9356811
Change-Id: I5167f8614c07bafb688983a360a008f76403b2b8
... when you want wifi to be really most sincerely off, because
settings restore is about to rewrite the conf file.
Bug 9032154
Change-Id: I6a3a34ac3f14ec43aa9d9cc0159fca6168ccd0a2
The BT stack needs to differentiate between applications that use
the new RemoteControlClient APIs to pass a playback position but
don't have one yet, and applications that use the legacy API and
will never pass a position.
Bug 9294855
Change-Id: I05cba82a073e6e0aaea1d8bbf9cc8c99da715f58
The specific bug is this: SIM PIN unlock attempt toasts are
sent from com.android.settings/.IccLockSettings which runs
as the phone process; NoMan wasn't having any of that and
was blocking the toasts.
With this change we treat SYSTEM_UID and PHONE_UID the same
for all security checks, and furthermore we guarantee that
all notifications and toasts from those UIDs will be
permitted.
Bug: 9098802
Change-Id: Idc788527aa2cb38e015fe92773766a514167999e
Bug #8725945
Selecting text in an EditText causes the View to have transient
state. This would in turn cause the View to be removed from its
ListView parent. When removed, the EditText would lose its
AttachInfo, causing all sorts of problems. Headers and footers
must not be removed, only detached. This is the part of the fix
in AbsListView.
Fixing AbsListView triggered a second bug: when a View is removed
from the Window manager, it would keep its parent assigned, thus
making it impossible to add it again to the window manager. When
a ViewRootImpl goes through doDie(), it must set its content view's
parent to null to properly cleanup.
Change-Id: I0489daa74f8f7fcf85526f0928f8925ec30d4f42
When building commands to send across NativeDaemonConnector, scrub
sensitive arguments to prevent them from being logged.
Bug: 8609800
Change-Id: I84b16791749264a010f7e59f9918f68d71bac6b9
There were some paths in LocationManagerService where
mRecivers was being accessed/modified without the lock held.
Update method names to indicate they need to be called with
lock held to make it more clear in the future when such a
problem may happen.
Change-Id: Ie2a9d019155ac7cedd1db298caca75b8fe382ca7
Some config.xml resources have values that vary based on the
configuration. A previous change caused initialization to
occur at a time when the configuration is was not yet available.
This change fixes the problem.
Bug: 8891502
Change-Id: Ia768dc2308cc6ae5f11812c6bce6a6e116cfd759
Otherwise there's nothing to kick us into scanable modes unless
the user toggles wifi.
bug:9217455
Change-Id: I6460305e3f299646433546598412f817579cc805
Telehony seems to sometimes be reporting the country before boot
is completed so can't persist the data at that time. Remember
and write it on BOOT_COMPLETED
Also, there are permission issues around writing the setting.
bug:9225156
Change-Id: Ifdf2243da71b0d2ce5743267842597937d790ef5
