A new switch was introduced in AndroidAtHome to deal with a race
condition between the WiredAccessoryObserver and the HW composer HAL.
When the new switch ("hdmi_audio") is present, we want to pay
attention to it instead of paying attention to the old switch
("hdmi"). This change checks at startup for the presence or absence
of the new switch and uses it if available, otherwise it falls back on
classic behavior.
see change ID I960cfc2f3e8df5342e7248a26fd313fdad2ca322 for the kernel
side changes.
see bug 6023647 for a discussion of the issue.
Change-Id: Ia2f2c399c3d85896ede0fff57ecbd51f332b3e0e
Signed-off-by: John Grossman <johngro@google.com>
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: Ic1548dd43935f45d4efc67f970abdc290a45f715
...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
Two things: (1) make sure the boot message is always positioned within
the entire unrestricted display, and (2) allow the dim background to go
on top of the nav bar when being used for the boot message (this latter
is really a hack that should be more generally fixed in the future).
Change-Id: I7261b044eb802a39cadff931b50a679ff18781d6
Backported from master, including a bug fix and a cdma enhancement.
Even if other people are sharing the connection (ie, carrier wants
default and tethered traffic on the same APN) stop using a carrier-
described APN when the tethering stops.
bug:5972599
Change-Id: I25e4831855e6b62c0c3ab3a6f4d4846aaee6ac50
This patch is adding a capability so that OEM can override USB mode
in case the device is boot up with OEM specific mode. (i.e. modem
debug, factory test etc.)
Bug:5964042
Change-Id: Ic8e23d302563ce71eedb74ce94cca8c65838a4f7
Add a small service to the high level core set of system services to
control the configuration of the native common time service. This
service is responsible for controlling policy regarding when the
common time service should be allowed to run, which networks it is
allowed to run on, what priority it runs at in the master election
algorithm, and so on.
Change-Id: I37308e882a0e8c4cd3e38c4f47b7c40b9150ba31
This is between the two previous attempts. I returned the part from the
original that was breaking gallery, but have some new code to detect when
something about the window params has changed that would require a
layout pass to make sure we still do a layout then, even if the window is
not currently visible.
Change-Id: I07745e1f66022583e3076b84cc8bbe8bd2acd48f
This fixes a complaint from carriers (that we used 8.8.8.8), but also
fixes the case where there is only room for one live radio
connection: the secondary connection (tethering) doesn't have a
default route to prevent on-device traffic from slipping out on the
tethering connection, but tethered dns is proxied through dnsmasq, so
it is appearing as on-device traffic and is unroutable. By switching
to the carrier-indicated dns servers we can use the host-routes
already set for those and kill two bugs with one fix.
bug:5898904
Change-Id: Ida8777687994f353b2d4f2c7db5d6ea4b6ac3882
This increases lock screen's thread priority from THREAD_PRIORITY_FOREGROUND
to THREAD_PRIORITY_DISPLAY to ensure it runs before other activities that
might stall lock screen when the screen turns on.
Change-Id: I14cf9f3f5c092817bc6cf2d0a254001a5d34f744
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
This fix does not include the change to ignore app tokens that are
hidden. This causes problems in some dialogs that stay hidden until
their app is ready to display, but need to perform a series of relayouts
during that time to get to the right size. Dropping this part of
the change still (mostly?) seems to allow us to avoid the bad states.
Change-Id: Ic052cb1499d3287f47e9ffeac5cd2470ee5a308c
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
In particular, don't do O(asec_apps * installed_apps) work during the
broadcast receiver's operation. On devices with many installed apps
and a large number of them moved to ASECs, this was causing the system
process to become unresponsive and the watchdog to fire -- which in turn
would initiate a restart loop, as the same package-installed broadcast
would then be issued again once the package manager rescanned the ASEC
containers, ad infinitum. With this change, the expensive call to the
package manager is only made once rather than asec_apps times.
Bug 5850283
Change-Id: I14e280ea1fa6af19cebc58869a20fbb599c92c8c
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
Also don't consider windows a candidate for layout if their app token
is hidden. This fixes a transient state where we are preparing to
unhide the window but have not done so yet.
Change-Id: Ife5299ffa003c1df1a4f787b7a2809cbf614ec16
