...in ActivityManagerService.updateLruProcessInternalLocked on bluetooth
Add more debug output to help track down what is going on.
Also fix a little problem where, when a service ANRs, if you ask to
wait and it still wasn't responding, the ANR dialog wouldn't be
shown again.
Change-Id: I5be2b1705a0a39ca2992624ae683945c5f38065d
Bring in latest asset drop. Apply grid padding programmatically
instead of waiting for asset. Remove alpha from directory animation.
Update save footer background to match spec.
Bug: 10700025
Change-Id: I8eef08f36d04767b78e91b23f72bdbebfbb02f58
When a file already exists on disk, try adding a counter suffix to
make a unique name. Move services near top of roots list, just below
recents. Remove "Documents" root.
Increase number of recents allowed from single provider, and add more
logging to diagnose wedged loaders.
When launching GET_CONTENT apps, wait for successful result before
relaying result; canceled requests now return to DocumentsUI.
Add CloseGuard to ContentProviderClients, since leaked instances can
keep the remote process alive.
Fix UI bug around trailing breadcrumbs. Fix bug that dropped Recents
from roots list. Add up action to Settings activity. Give our
activity a default icon while waiting for async roots to load.
Bug: 10818683, 10819461, 10819461, 10819196, 10860199
Change-Id: I7b9e26b1cf8353dd3175458b23da2b4bda6c5831
Previously I was calling setIsConnectedToProvisioningNetwork(false) always,
but all MDST's receive every broadcast. Thus we could over write an MDST's
mNetworkInfo.mIsConnectedToProvisioningNetwork to false, unless the MDST
that was set to true was last, i.e the code was order dependent.
If the provisioning networks value was false instead of true
when handleMobileProvisioningAction was called we wouldn't invoke
mdst.enableMobileProvisioning because network info would be null.
Thus the provisioning network would never transition to CONNECTED and
a default route wouldn't get setup and the browser couldn't access the
website.
Now setIsConnectedToProvisioningNetwork is only set to false when the
apnType matches and we won't indiscriminately change it and are not
order dependent.
Bug: 10853805
Change-Id: I68a4f9bdf5dc18d90f4cdef7a60811f57be67261
- CaptureResult#getRequest is used to tie a result to a request (for convenience)
- Add new CaptureFailure class to describe capture failure
- Results/frame numbers also return frame numbers, sequence ids
- Captures now all return the sequence id
- A sequence id onComplete is available in the CaptureListener
Bug: 10360518
Change-Id: I9ebaa45698c718a1185b5ae920b7975925fe2f60
Gah I messed up when refactoring so it would always be told
RAM is low.
Also slightly tune the low memory parameters to go into low
memory states a bit more aggressively.
Change-Id: I5f970349760ad349d515a85c266ab21b387ee353
Bug 10617080
Fixed typo:
"Determine if AccountManager for You"
-->
"Determine if AccountManager is for You"
Change-Id: I5b8f1368dad72bbbeb581132f480baf46a029be8
...device to another mode (portrait or landscape) on Main page.
So, it turns out that Bundle claimed to have an invariant that either
mParcelledData or mMap would hold its data, never both. The new
implementation on top of ArrayMap assumed this was the case. However,
there is one situation where it is not true: an application can take
an existing Bundle that contains data, and call readFromParcel() on it.
The implementation of readFromParcel() would just pull out the
parceled data and stuff it in to mParcelledData for later unparceling,
even if that Bundle already had a non-empty mMap.
To fix this, we just look for this case in readFromParcel() and
immediately unparcel at that point into the existing map, using a
new unparcelling method that doesn't rely on the target map being
empty.
Change-Id: Ib816b6876a6cd2760b7a3372c7a79ca2f12dfeba
The user has to explicitly enable a print service from the settings UI
before using it. Usually, users very rarely if at all interact with print
services, therefore all print service management task are performed from
the print settings. We also have to get user consent warning that the
user's data is about to be given to a third-party app. We now post a
notification allowing the user to go directly to the settings screen to
turn the service on.
bug:10447510
Change-Id: Iea56c0825f0bf38328ad94912f0ea5576e9339b3
bug:10863163
This fixes two issues
The check for pure translation was incorrect. It was fixed and renamed
for clarity.
Certain matrix paths weren't setting kTypePositiveScale. For
simplicity (and because positive scale is simple to check) removed
flag in favor of dynamic checking.
Change-Id: Ic5ce235653ef49a68b8b242bd89fc2e95874ecc9
This patch fixes behavior where attempting to place the cursor at
the end of a string where the last character is a combining accent
actually placed it before that accent. This was especially annoying
for editing Thai text, because it made it difficult to delete a
trailing tone mark.
Fixes bug 8947569 "Can't place cursor after combining accent" and bug
10398332 "[Thailand] Thai Language(IME) -- Can't delete Thai tone mark
while writing message"
Change-Id: Ida1933c8f0ab6cdb0200db39891e9389e4bdba86
Apps without sdcard_r or sdcard_rw are still able to write to
their package-specific directory, but someone needs to first make
that directory on their behalf. This change will delegate the
mkdirs() call through to vold when an app fails to create directly.
MountService validates that the path belongs to the calling user, and
that it's actually on external storage, before passing to vold.
Update Environment to make app-vs-vold paths clearer.
Bug: 10577808
Change-Id: I43b4a77fd6d2b9af2a0d899790da8d9d89386776
Moving a task to the bottom was also moving its stack to the back.
Since chrome always finishes by calling moveTaskToBack this put
the home stack in front of the application stack and would cause
bizarre window layering effects.
Definitely fixes 10764463.
Maybe fixes 10678010.
Change-Id: Ic202ae4fad44b36a8444255764d2135fccd4743d
1. Layout was not called after pressing the print button if the
print attributes did not change. This is not correct since the
previous layout calls were for preview purposes and the one
after pressing print is not for preview. Hence, we always have
to do this layout.
2. After layout we decide whether to ask the app to write some
pages. We ask for a write if we do not have the pages selected
by the user or the document changed (if the page count changed,
the document type changed, or the app told us that the content
changed). We were not computing correctly whether the document
changed since we compared the size but the document info the
app passes in after a layout does not have the size yet. We set
the size after a write. So for layout purposes we should ignore
the size. We only care if the page count, document type, or
content changed where the latter is reported by the app in
the layout callback.
3. We were not updating the PrintJob after setting the data
size of the printed document.
4. Disabled debugging.
bug:10835370
Change-Id: Ic3b2871b4e954cdf610f8cf806de5fc6588a6bec
