Change 1/2. Change 2/2 will setup the class loader namespace for
shared libraries.
This change sets up shared libraries class loaders for applications
and for dexopt.
bug: 111174995
Test: DexoptUtilsTest, device boots
Change-Id: Ie9a2b4eaa85cda59951703433f7a2d03bc12095d
By default, the UIDs collected are all system users, i.e. UIDs in the range
[1000, 2000).
Bug: 119089294
Test: KernelCpuThreadReaderTest#testReader_byUids
Change-Id: I162916f2238aad975b657c9299cb9035718768bb
BitUtils is a fairly generic place where all framework engineers should
be able to contribute reusable code.
Test: test after merge in gerrit UI
Change-Id: Ibd00f0618e3e85aab466cedc43605115994cca4f
This means that instead of returning all frequencies, we return
KernelCpuReader#NUM_BUCKETS frequencies.
Test: Unit tests for bucket creation and usage in KernelCpuThreadReaderTest
Change-Id: Iea0996f642deecae8ce66e5122045a0694fac03b
This change only renames methods, there is no behavior changes except
using the new restore methods instead of clear.
Test: unit tests
Change-Id: I35ae966461657e2e2a67e916d752b9ee53381c83
BatteryStats calculates power usage of the device and various components
(such as apps). This information is used, e.g., in the battery panel of
Settings. We now log it to statsd. It can be used for validating how
good the information displayed in Settings is. In the long-term, it is
likely not ideal for off-device calculations, since that can be
hopefully estimated using statsd's raw data.
Three atoms: one for the total power use, one for the power use of each
uid, and one for each non-uid component. Since they will all likely be
pulled together, StatsCompanionService will provide stale data for
BatteryStats pulls called within a second of a previous BatteryStats
pull.
Also in this cl:
Remove StatsLogEventWrapper.writeDouble. Statsd doesn't support actually
writing doubles into its proto reports, so having this function is
misleading (the data will get to statsd and then be completely ignored).
It's less confusing if we don't pretend it does something.
Change-Id: If80bab8ea938afa4632535bb88ff59879fbe8099
Fixes: 119111972
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testDeviceCalculatedPowerUse
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testDeviceCalculatedPowerBlameUid
Test: BatteryStatsHelperTest#testDrainTypesSyncedWithProto
SubtitleView.mAlignment is null by default. This can cause undefined
behavior if mAlignment is passed to StaticLayout.Builder.setAlignment().
As the previous behavior of StaticLayout with alignment equals to null is
same as ALIGN_CENTER, this change uses ALIGN_CENTER as default value.
Bug: 119221721
Test: bit CtsWidgetTestCases:android.widget.cts.CheckedTextViewTest
Test: bit CtsWidgetTestCases:android.widget.cts.EditTextTest
Test: bit CtsWidgetTestCases:android.widget.cts.SwitchTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewTest
Change-Id: Iefd069db449a7fe3d68f6f3e5ebcfcbf1e588962
1. Add the key of query arguments and match method
in DocumentsContract.
2. Implement new querySearchDocuments method in
DocumentsProvider, ExternalStoragProvider and
FileSystemProvider.
Bug: 111786939
Test: Manual Test
Change-Id: I04e9f2be971f10ac1e9584a3486c948aaddea0a4
In previous design, the IME focus is changed when receiving
window focus change from ViewRootImpl.
For Multi-Display concept, it should be needed to aware the top
display focus changed in different displays but both are already
had the focused window without change case.
Sending REPORT_FOCUS_CHANGE when top display focus changed for
ViewRootImpl, let IMM can re-focus IME window on right display.
Bug: 117491872
Test: atest ActivityManagerMultiDisplayTests
Test: atest FrameworksServicesTests:DisplayContentTests
Change-Id: Ia46738a5da6dbc334bf937b0f6656a57523c28a7
Bug: 117347671
Test: Followed steps in b/119296586#comment1
Test: Background/color changes properly when launching BP from
managed / unmanaged profiles
Change-Id: Ia0368041540b65b41957d2adbcaa75c0739f62f1
An advanced multi-display support is requested for certain Android
form-factors so that user(s) can type text on each display at the same
time without losing software keyboard focus in other displays. This is
not possible in existing Android IMEs that are built on top of
InputMethodService class, because the assumption that a single IME
client can be focused at the same time was made before Android IME
APIs were introduced in Android 1.5 and many public APIs in
InputMethodService have already relied heavily on that
assumption. Updating InputMethodService class to support multi-client
scenario is, however, quite challenging because:
1. doing so would introduce an unacceptable amount of complexity into
InputMethodService, which is already hard to maintain,
2. IME developers still need to update their implementation to be
able to support parallel requests from multiple focused IME
client, which may require non-trivial redesign in their side
(e.g. input decoder, typing history database, ...), and
3. actual use cases for multi IME clients are expected to be evolved
rapidly hence the new protocol is not yet stable and not yet ready
to be exposed as public APIs.
This is why a new type of IME needs to be designed and developed
specifically for such special multi-display environments, rather than
reusing existing InputMethodService public class.
Note that there must be no behavior change unless multi-client IME is
explicitly enabled with 'adb shell setprop', which requires root
permission.
See multi-client-ime.md for details.
Fix: 114662040
Test: Manually verified as follows:
1. make -j MultiClientInputMethod
2. adb install -r $OUT/system/priv-app/MultiClientInputMethod/MultiClientInputMethod.apk
3. adb root
4. adb shell setprop persist.debug.multi_client_ime \
com.example.android.multiclientinputmethod/.MultiClientInputMethod
5. adb reboot
6. Try multiple text input scenario
Change-Id: I41dfe854557b178d8af740bc2869c936fc88608b
A less resource hogging reader for reading proc files in string
format. It is singleton and thread-safe, so all downstream clients
share the same instance to avoid duplicate allocation. It reads
the entire proc file all at once (to mimimize the impact to the
kernel) into a reusable char[] buffer (to prevent frequent GC). A
read lock is automatically held for the client when a valid file
iterator is returned. Client MUST call close() to unlock it or take
advantage of try-with-resources.
The reader keeps an error counter. It rejects further requests if it
has accumulated 5 errors, to prevent log spam. The reader also has
a 500ms cache, which can be bypassed with a parameter.
Bug: 111216804
Test: atest FrameworksCoreTests:com.android.internal.os.KernelCpuProcStringReaderTest
Change-Id: Ifa5213a5c7baf95d62f74486815030d9aa54ca28
Previously reverted due to b/72554856, fix for that in topic.
Original commit message:
Security model for moving sharesheet to systemui
ResolverActivity (still in frameworks) now requests a "permission token"
that it hands to a stubbed system ui activity ChooserActivity.
This permission token allows an app (SysUI) with the signed permission
"START_ACTIVITY_AS_CALLER" to call
ActivityManagerService#startActivityAsCaller. Permission tokens are a
one-time use, limited-time offer.
Test: runtest systemui && manual testing
Bug: 69850752
Change-Id: Ia50e21e2f8c6b6d0ed7207625e3b5aef214396bb
* changes:
WindowInsets: Annotate nullability
WindowInsets: Add Builder
WindowInsets: reimplement WindowInsets on top of Insets
WindowInsets: make WindowInsets.inset() public
We expect some proc file reading to fail when processes or threads
finish execution while we traverse their proc files. We should not
pollute logs when this traversal fails.
Test: Inspected `adb logcat`
Change-Id: Id811a1e6b5084a8a3a903a892a99e317d1e3ac7f
In the previous code, updateTrackingAssociationsLocked() was called too early.
There's still code that changes procstates, so let's move
updateTrackingAssociationsLocked() to the end of updateOomAdjLocked().
Also change Slog.w() to Slog.wtf() so we can monitor it on APR.
Also rate limit the WTF to at most one in ten seconds.
Bug: 118826162
Test: Boot with and without the fix and make sure the number of the warnings
reduces.
(We still have a couple WTFs from during a boot with this CL, which requires
further investigation.)
Change-Id: Ifa1fe85de82fa1d1d8f843372c54c1248966a62a
