While services themselves don't need an action when an explicit
component is specified, services in GMS may be different. In
the case of instant apps, the resolver service is hidden behind
a proxy that uses the action to route to the actual, implementing
service.
Bug: 36594944
Test: see that ephemeral resolution occurs
Change-Id: Id8c352614f780dc63f36c65be2ddb2d480b6846b
Framework resources have their mResDir set to null, since the framework
resources are implicitly always included. Guard against null
when checking to see if the Resources mResDir matches the asset path
WebView wants to inject itself into.
Bug: 36953234
Test: manual
Change-Id: Ie3dc0cc1240441a2466585224cdc7c15555c66bf
Turns out we run this code during early boot, before the device idle
service has even been constructed yet. Find another way to achieve
the needed service execution.
Bug 36865930
Test: manual
Change-Id: I8e3304f37c3a5ee125b73aef2b7d7c7b387aa200
We have seen issues where we fail restarting a process
because there are so many services with so many pending
start arguments that we hit IPC limits. So instead of
doing an IPC for each service start, collect them together
in a list that is sent once, and send it inside of a
ParcelledListSlice to control how much data is written
inline in the IPC.
Test: boot and ran
Change-Id: Ifed26ccdf535871e577fc02c7ef1d09060ab06ca
Add null checks to ScrollView and HorizontalScrollView for checking
the revealOnFocusHint. This should never happen in code called by
the framework, but some apps were hitting it.
Bug: 36379645
Test: none
Change-Id: I220eb88d82126ff08f47a7c2a7fbdddebf07de81
As per CDD: The "android.*" namespace for intent constants is reserved
for public
Android API in AOSP. (Whether public to the full SDK, @SystemApi or
defined in AOSP support libraries.)
ACTION_SERVICE_STATE intent is generally useful for system/oem
apps thus move to system api
Bug: 33679956
Test: Manual
Change-Id: Ie38b53f077e8a013351d35387f9133e0ebb26cc9
This allows more fine-grained control than getting all installed
providers for a user, when you might only want to check for a particular
package. For instance, Launcher can use this API to surface widgets per
app without having to ask for all the widgets.
Test: Unit test on AppWidgetServiceImplTest
$ runtest --path=services/tests/servicestests/src/com/android/server/appwidget/AppWidgetServiceImplTest.java
Bug: 34940468
Change-Id: I182bf1c012d31182024422fc4a63f57f151c3ee5
Instead of trying to be clever by poking at underlying flash part
sizes, rely on the fact that device storage printed on retail
packaging is a power-of-two value.
For a typical device with a 23GiB data partition, this will return
a value of "32GB" which matches the retail packaging.
Test: builds, boots
Bug: 34827187
Change-Id: Ib4cf7f637dffc9238252e1fedcd86dc8b5cf656d
Platform is now providing autofill feature. Disable WebView's simple
form data save feature for platform O and above.
Test: Removing the functionality and the test
Bug: 36869838
Change-Id: If6b9fc12edbe4146fca99d9c6ef8fde36d61f852
Typeface.NORMAL/BOLD/ITALIC/ITALIC_BOLD is used for specifying relative
from current Typeface. For example
Typeface face = Typeface.create("serif");
Typeface thickerFace = Typeface.create(face, Typeface.BOLD);
Typeface moreThickerFace = Typeface.create(tickerFace, Typface.BOLD);
For the purpose of providing font information, we should use weight/italic
value instead of style in Typeface.
The Columns.STYLE field was kept for preventing runtime crash of demo
apps.
Test: Manually
Change-Id: I732e8ee04a66f61321fc0a98dbfb8fdc0a4dd7a4
In order to clear the measure cache, we need to requestLayout
when updating the child layout params. To see why, consider the case of
a Frame or Linear layout which will measure different heights
depending on the (top/left/right/bottom)Margin parameters of it's
childrens layout params. Now imagine the following sequence of events:
1. We request a layout on the FrameLayout
2. We measure the FrameLayout and place a value in the cache.
3. Now we update the margin parameters on one of the frame layouts
children. Because the parent already has a layout requested
we don't call parent.requestLayout (see View.java#requestLayout),
and thus the parent measure cache isn't cleared.
4. Now we measure the frame layout again and we incorrectly
used the cached value.
Calling to requestLayout when the child layout params
change clears the cache properly. If the child didn't
call request layout from it's own relayout, it must mean that
a layout was already pending (step 1 in the sequence),
and so no more work should be triggered besides clearing the cache.
Bug: 33095565
Bug: 33308065
Bug: 34388764
Test: Manual case in bugs.
Change-Id: I9148f32530588e4dc859297f9658f506b38e72f0
