Initialize the cache path only if the container exists.
This did exist before but was somehow removed.
Fix a known test failure as well.
Change-Id: I63219369b0e7abca4919fbde2a04035a0fea9e35
This is to avoid flashlight apps that had been using reflection to access
this API after this class was removed after eclair.
Change-Id: I26ed929abad93345468eb33d4a15977a31ebea7e
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes a problem with Network Location not working after SetupWizard until the
network state changes.
Change-Id: Ief81b76beb5cc90b2ca7d8aa2d4c99221898f01d
BUG: 2671347
Signed-off-by: Mike Lockwood <lockwood@android.com>
When the user selects a "Silent" notification sound, the Uri encoded
path is an empty string. Setting this Uri as the data source of the
MediaPlayer used to play notifications caused the completion listener
to not be called, which with the AudioFocus logic causes the Music
app to pause and never resume. The NotificationPlayer modifications
cause the MediaPlayer for the notification to only request audio
focus when the data source is not empty.
The audio focus code in AudioService is defensively synchronized
against a unique lock, and the exception observed in bug 2670395
is explicitely caught in case another edge case wasn't caught by
this fix.
The AudioFocus handling in AudioManager is modified so only the
requestAudioFocus and abandonAudioFocus methods are meant to be
used, as registerAudioFocusListener and unregisterAudioFocusListener
provided no additional functionality over the request/abandon
methods. abandonAudioFocus() also removes the listener from the
map in AudioManager since after abandonning focus, the listener
would no longer be called.
Change-Id: I3b553ee8a8163c25e01117d7e5479dd5fdfa7c6b
It looks like there was a subtle bug where Process.setOomAdj() could
return false just because the given process doesn't exist, even though
it is documented to only return false if OOM killing is not supported
at all. This would cause the activity manager to fall into its code
path of trying to clean up processes itself, which it does a much
poorer problem at. I am thinking we may be seeing this problem more
now that the activity manager is killing background processes itself
when there are too many of them.
In addition, this change cleans up and reduces some of the logging
around killing processes.
Finally, try to improve process LRU management a bit by taking
into account process dependencies. Any dependent processes are
pulled up in the LRU list with the processes that is actually
moving. Also, we bring a process up if someone accesses its content
provider.
Change-Id: I34ea161f839679345578ffe681e8d9c5d26ab948
When we switch to another network (or even just lose mobile data) the mobile
interface is either brought down or destroyed altogether. That means any
throttling rules we've told the kernel about get lost.
This change notices when our interface comes up and reinstates throttling
if needed.
bug:2660287
Change-Id: I4c6ebf78acc59ed66b95984a1e8b7c2ffbc22dcb
With the .apk file names now changing during an update, we need
to make sure to flush all caches related to a package when the
package is removed. Otherwise we can continue to use the old
package, since its old file may still exist if we try to load it
too soon.
Change-Id: I15f08dffca3feac999dbca4f24bef12a30ca0a66
The SimpleDateFormat was being cached and new timezone not being applied. Make sure
to apply the new timezone to the format object as soon as it changes.
Change-Id: I72abfef2e14cf5db5a6e8cb71b053380b695495c
The Looper on the thread created in order to be notified of the
playback completion of notification sounds, was never stopped, causing
the threads to stay around in wait state.
The fix consists in quitting the Looper used for the previous sound
when a new sound is started.
Change-Id: Ia4b3d16b5447ffafacc093db3a7fe05574089935
The start and end times were precisely the same so, a ">" check needed to be ">=".
Also removed useless code and removed the potential problem where continuous gradual
advancement of your start and end times would prevent resets.
bug:2629717
Change-Id: Ieced1965a5611a9b555e92bcf924ec350f2a80db
We were updating limits and such before, but we were not applying them
to the current situation if we were already throttled. Now it can result in
us throttling or changing our throttle rate or unthrottling or even making
the ui come or go (disabling/enable throttling)
bug:2622543
bug:2619879
Change-Id: I64a62634d54f4768ab8625f8d72f9f66a239cb19
When a service transitions from foreground to background, we now push it
to the top of the LRU list. Also fix the activity manager to take care
of killing processes if we go beyond a reasonable number of background
process to keep around.
Change-Id: Ic9f44c02af7a111ee6f1d06142386b301948bafe
Need to clear the attached hidden flag on the window, even if it does
not yet have an actual surface.
Change-Id: I0a90f6b03cd8e347a3eae4d6bea3ab93f7128bf4
Throttle is useless when ntp and imsi are not yet ready. In the real world
the second check won't happen for 10 minutes letting people do what they want
for 10 minutes each boot. Trim this down with a quicker first check.
bug:2614247
Change-Id: I84ec33f31e8fed37b3933482fbc187b8e9e94e79
Previously, it was conceivable that a 3rd party application on a non-GED
device could publish a service that supported the (hidden) IBackupTransport
interface and spoofed the Google backup transport's package and component
name. This could allow it to secretly intercept all data moved through the
backup mechanism.
Fix by ensuring that the package in question exists and is part of the
OS itself (FLAG_SYSTEM in its ApplicationInfo description) before binding
to it.
Fixes bug #2457063
Change-Id: I3487572be45c2014fa209beacfe3ac6f8270f872
An ANR has been reported because somebody else was hogging the Netd
link. We can't pause the server thread for that, so make a new thread.
bug:2609904
Change-Id: I0430a08621da1cda0a0010ce15826cceee59a529
Cleanup of duplicate code
Caching Ntp data so we don't hit the network as often
Clearing out of MRU data when we switch to a new sim
Sending notification after we reset byte counts
bug:2605277
bug:2605272
bug:2597530
bug:2576057
Change-Id: I3df526bae6374f6ae56fed67b0defad2b4fabefd
The value returned is purely a function of what's passed in, all
following final members.
BUG=2606839
Change-Id: I506fb9b1f3be965576c2b3317a30ff1f990ccda3
Previously, this status icon reflected just the incoming
call behavior:
- gone for audible (with or without vibrate),
- wiggling phone for vibrate,
- silent (speaker + X) for no audible ring or vibrate.
Now that silent mode has changed (see VIBRATE_IN_SILENT),
you can easily get into a state where this icon is
confusing by setting the incoming call ringer to *never*
vibrate but setting the overall device silent state to allow
vibration (VIBRATE_IN_SILENT=true). In this case, rocking
the volume all the way down would show a wiggling phone
(because the device is in vibrate-only mode) but the status
bar would show speaker+X (because the incoming call would
neither ring nor vibrate).
Now these two icons are consistent. This means, however,
that if this special condition is set by the user (device
vibrates in silent mode, but incoming calls should never
vibrate) and the device is in silent mode, the status bar
will show a wiggling phone even though incoming calls will
not vibrate the device. This puts the ringer on a more even
footing with other apps on the device, which may elect not
to vibrate even if VIBRATE_IN_SILENT=true overall.
Bug: 2598014
Change-Id: Ib942f68738d77ab0d9b9da4fac718ae5957c133c
