The default behavior for sending a message to a premium SMS
short code (or suspected premium SMS number) is to ask the user for
confirmation. Enable the user to set a default policy ("remember this
choice" checkbox) to always/never allow the app to send SMS to
premium short codes in the future. The policy can be changed by
the Settings app in the app info screen.
Bug: 5513975
Change-Id: I15f45f34dc4da4aef7d0efd675be6bc3a4ceb720
1. The layout containing the text of a Switch is initialized on measure
and if an accessibility event is fired before that then a NPE happens.
bug:7169419
Change-Id: Iee3c01ca9157d14d228c4ff33c0810507e0e25a7
When verification and encryption is used, the temporary file was deleted
prematurely.
Also, on next boot-up, scan the directory we use for temporary files to
clean them up if the user rebooted in the middle of installation.
Bug: 7132197
Change-Id: Ic9e8aab9a664ca00d9ac16f72e53fc43d78d21bc
Bug #7165793
A ViewRootImpl's root view can be null. Check for this condition to
prevent an NPE invalidateWorld(). Other messages perform a similar
check to properly handle the case where mView == null.
Change-Id: I5bcfc41c48a469d38b21be74df2f6c715b0f9352
Oops. Stacked bugs: first, the desired user handle was not properly
being passed from the call() entry point to the database operations;
then on top of that, the client-side cache management was still
looking in the local user's cache for the data, so a request to read
a different user's settings would return the local user's instead if
that key was already known to the local user's cache.
Reads and writes of a different user's settings are now uncached,
so they're relatively much slower. They're rare, however, so this
is not something to worry about unless we encounter a real world
case where it's a significant factor.
This CL also adds a bit of cross-user settings read/write testing
to the existing provider suite. These new tests caught both the
known wrong-user-write bug and discovered the client-side cache
bug, so yay.
Finally, the existing wholesale mutual-exclusion approach would
deadlock in certain circumstances due to the fact that the
settings database creation code might have to call out to the
Package Manager while populating the bookmark/shortcut table,
and the Package Manager would then call back into the settings
provider in the course of handling that request. The synchronization
regime has been significantly tightened up now: now the database
code [which is known to deal with concurrency itself] is allowed
to cope with multiple parallel openers of the same db; this
allows the settings provider to avoid calling out to other parts
of the system even implicitly while its internal lock is held.
Change-Id: Ib77d445b4a2ec658cc5c210830f6977c981f87ed
1. For accessibility purposes it is important to be able to associate
a view with content with a view that labels it. For example, if
an accessibility service knows that a TextView is associated with
an EditText, it can provide much richer feedback.
This change adds APIs for setting a view to be the label for another
one and setting the label for a view, i.e. the reverse association.
bug:5016937
Change-Id: I7b837265c5ed9302e3ce352396dc6e88413038b5
Now that surface flinger lets us set a display projection,
the window manager no longer needs to place a black frame
around the content when simulating a different display size.
Bug: 7139798
Change-Id: I6014390f47444633d434ccf918cee5ff7b502869
The mAttachInfo.mSystemUiVisibility value was changing in
View.dispatchAttachedToWindow but
mAttachInfo.mRecomputeGlobalAttributes was not being set.
Consequently ViewRootImpl.collectViewAttributes was returning
without updating the subtreeSystemUiVisibility. This is fixed
by calling needGlobalAttributesUpdate in dispatchAttachedToWindow.
WIthin ViewRootImpl.collectViewAttributes the assignment to
subtreeSystemUiVisibility was only being made if
mAttachInfo.mSystemUiVisibility was changed within
collectViewAttributes. But mAttachInfo.mSystemUiVisibility
was changing outside of collectViewAttributes in
dispatchAttachedToWindow. Consequently subtreeSystemUiVisibility
was never updated. By looking for a mismatch between
subtreeSystemUiVisibility and mSystemUiVisibility
subtreeSystemUiVisibility gets assigned whenever it is out of
sync.
Fixes bug 7091817.
Change-Id: I1e97a7dec14dc9594876175ae26370fb9030a8a6
The reason for not to fix the test instead with new annotation
is that it's preferable to have a single version that works for
all platforms.
This can be revisted once we have enough platforms released to
not to care about the older ones.
Change-Id: I42557f920702e5a65e39a3fea80533bd07b54367
