This commit swaps some internal details of libcore for some
abstractions on dedicated "internal facing" APIs. This reduces the
number of internal APIs used. There is an associated change in
libcore/
Bug: 111055375
Test: build / boot
Change-Id: Idddada1922701bd15475c840eaa76c505e545d33
Process of tombstoned have changed the generation flow for
tombstone, and dropbox could not be notified when generating new
tombstone file any more, so dropbox could not copy and compress
tombstone file to /data/system/dropbox. We need to modify
observer events from CLOSE_WRITE to CREATE, and it could
work normally.
Bug: http://b/111608961
Test: 1 After tombstone is triggered, we could see the tombstone
file in the data/system/dropbox directory.
Signed-off-by: Haoran Li <lihaoran5@huawei.com>
Change-Id: I9d6a31773e4a58658ffab214b1e337f27e9f3ae6
Widen the definition to take advantage of errorprone support.
Bug: 72666911
Test: m
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: Id792ee70b41b786da717f916e143786fe6308937
Stop using bouncycastle as requested in the bug.
Bug: 111440841
Test: 1. Without changes
a. adb shell bmgr transport android/com.android.internal.backup.LocalTransport
b. adb shell bmgr backupnow com.android.providers.settings
c. adb shell ls /cache/backup/1/_delta/<kv_package> #=> Base64 encoded keys
2. Build and flash this CL
a. adb shell bmgr restore 1 com.android.providers.settings #=> verify stuff restored
b. adb shell rm /cache/backup/1/_delta/com.android.providers.settings/* /data/backup/com.android.internal.backup.LocalTransport/com.android.providers.settings
c. adb shell bmgr backupnow com.android.providers.settings
d. adb shell ls
/cache/backup/1/_delta/com.android.providers.settings # Verify same keys as 1c
Merged-In: I305bbae0e0af3639c1d45def19872e6da84624df
Change-Id: I305bbae0e0af3639c1d45def19872e6da84624df
(cherry picked from commit 7a6e032719)
Track changes in libcore to remove a constructor + lint
import order changes. Instead of the constructor a utility
method is introduced.
Test: Build / boot
Bug: 111055375
Merged-In: Id683a9d9d6e27d4c8df623dae189da9e74a6d410
Change-Id: Id683a9d9d6e27d4c8df623dae189da9e74a6d410
Expose Binder Proxy Tracking by Uid from the native side. Enable
tracking for SYSTEM and killing of any bad behaving uids.
Merged-In: Ifd6d0f30a93fad406417dd83c1495c105bced974
Change-Id: Ifd6d0f30a93fad406417dd83c1495c105bced974
Fixes: 63901963
Test: bit FrameworksCoreTests:android.os.BinderProxyCountingTest
(cherry picked from commit 55182464fb)
Message app or other apps will use some format code or controll
code on SenderName to fit RTL or other design, and symbols will
produced by these code. The special code pattern not include these
code, so it will go charIcon flow.
Although these code is not visible, we should just ignore them to
get symbol strings
Change-Id: I20ef459b10ba7504ec0c997ed815cb485817d2bc
Fixes: 109746235
Test: Check notification form message app on RTL
Test: atest SystemUITests
Rationale: hexdumps are mainly used when verbose logging is enabled,
which means that callers are rarely exercised (let alone tested).
Crashing on unchecked null pointers doesn't make debugging any easier,
nor production code any more robust.
Moreover, this is the behavior of system.out.println() and other
logging APIs.
Test: runtest -x core/tests/coretests/src/com/android/internal/util/HexDumpTest.java
Bug: 110177912
Change-Id: Idccd81a5654ed0f7fee6b27177941bf8c311973e
Pruning was intended to remove targets corresponding to
now-missing packages, but in practice causes the list to
briefly disappear any time packages change:
PACKAGE_CHANGED ->
ResolverActivity.rebuildList() ->
ChooserActivity.onListRebuilt() with an empty
ResolverActivity.mDisplayList
In practice package changes happen all the time, so this
jank happens fairly often. (It contributed to b/67622422 as
well, since all this list rebuilding started animations that
locked out user input.)
This CL removes the old pruning process (comparing targets
against mDisplayList). Instead, we note that mDisplayList
got emptied, and lazily empty our own mServiceTargets once
we start getting responses back from all the services we
just re-queried.
The long-term fix here is to just rebuild all of this stuff.
Test: (1) share from Chrome
(2) toggle the enable state of some random package
to trigger PACKAGE_CHANGED, e.g.
adb shell pm (enable|disable) com.android.egg
(3) watch for jank
Bug: 109676071
Change-Id: Ie9d59b8f4b8cc8343beb40cbad6b8d52e5639082
The animations could go wild at times, leading to overlapping
messages and ugly renderings. This improves the animations
overall and fixes those cases.
Test: add messages, observe animations
Fixes: 78114531
Fixes: 80409521
Change-Id: I6f21b87706ccc2e85f1edbd9489e4bf7e686d7d8
The animation---which was responsible for causing relayouts
that would in turn bind views, which involved package
manager roundtrips---would lock out interaction with the rest of
the share sheet for at least 400ms while the animation ran
(often much longer if services were slow to start or respond).
Now the main UI is never blocked, and direct share targets
can take as long as they like (up to 2sec) before appearing.
It's really fast now, basically.
Bug: 67622422
Bug: 63521992
Test: atest com.android.internal.app.ChooserActivityTest
Change-Id: I21826e282226f2b2ce6d3d1b5862dbfc449f5918
In a situation where a focused view consumed only the UP of a key
and the unhandled key manager would focus a listener, it wouldn't
drop focus unless the original key was pressed/released again.
This updates the record of captured keys before it can be consumed
in the view hierarchy.
Bug: 79993136
Test: Added a test for this to cts ViewTest#testUnhandledKeys
Change-Id: I5dfdcf16c5c41e9ad51cb62b385580c5493e8520
