This class is never instantiated (and should be deleted in the future),
doesn't need to inherit from anything, and only has one method that is
used (to get an instance of BpServiceManager defined here). Deleting
unused code, and we can delete the class once apps stop linking against
it.
Bug: 135768100
Test: TH
Change-Id: Ie19e099551b10599a4b7bab29b35d78d66cd3442
We are planning to use this metric to detect leaks.
This CL also decouples the actual memory sampling from AM. This means:
- Less time locking the pid list (we used to lock and then read proc)
- Less serialization / deserialization for the parcel
- Simpler to evolve (e.g. removed the HWM-specific method in AM)
Change-Id: I87a7243156dd8c88cfa85038e7e6cf4963e271e1
Test: manual, MemoryStatUtilTest, UidAtomTests
Bug: b/135418017
Switch to a single PacketSocketAddress constructor to
avoid multiple unnecessary overloads in the
Core Platform API.
Bug: 133196453
Bug: 124232146
Test: build only
Change-Id: I30533ac3aa99c2cd09e8c624fedf6000b0f52c11
Also a few utilities that were in the way, and some opportunistic
cleanups.
Test: FrameworksNetTest NetworkStackTest
Change-Id: I385070e2044fd967cb18f1ffea9a86a4627b742e
Using this flag when binding to a service will
allow the bound process to be held at a low
oom_adj of 250, so that it can be expunged to
reclaim memory if a more user-visible app needs
it.
Use for bindings such as job services and other
connections that the caller can easily recover
from and restart if necessary.
Adjust the lmk thresholds to use this oom_adj
as one of the levels, so they're killed before
perceptible apps (such as foreground services).
Bug: 135219821
Test: CtsAppTestCases
Manually check notification listener oom_adj
and dumpsys activity services output
Change-Id: I9f6d0891d842e4d12f7995b9b1a8f57b0903a16d
Set a trim-level threshold to debug.am.run_gc_trim_level to activate it.
Bug: 135148702
Test: Manual test with "setprop debug.am.run_gc_trim_level 0", run a lot of
heavy apps and take pictures, and check logcat for the "force_gc" event log.
Test: Manual test with "setprop debug.am.run_mallopt_trim_level 0", run a lot of
heavy apps and take pictures, and check logcat for a debug log.
Change-Id: I73b4dc7374e85e9a22c98ab17da53aa6cb25a188
This change also enables log when keepalive is started.
Bug: 134352656
Test: 1. atest android.net.cts.ConnectivityManagerTest#testSocketKeepaliveLimitTelephony
2. atest FrameworksNetTests
Change-Id: I408750fa0bceb0c1c26afb5fead4e44fb824fbc1
When the configuration changes between landscape and reverse
landscape, the app will not receive onConfigurationChanged as
orientation is not part of the public portion of the configuration.
However, when the ViewRootImpl receives such a configuration back from
relayout, it will force a layout of the client views
(see updatedConfiguration in performTraversals), this is because
Configuration#equals compares the non public part of the configuration
as well. This CL changes MSG_REPORT_RESIZED to handle the configuration
changing the same way performTraversals does, so that the app consistently
receives a configuration change.
Bug: 134643273
Test: Manual
Change-Id: If016bcd9a5b8d2a7efc5e1ab3c82a88a608caf8b
This is still sent in an intent.
Bug: 131764329
Fixes: 131764329
Merged-In: I56c86b0c1912064d5a642991df32d2cefb6a8d5b
Change-Id: I64b9d632be97dc51e6085162371bb8c19f410258
(cherry picked from commit e546cb0bd16b7359feeb3c46ba52e64cf91ae4d3)
To determine if the CPS can get/send messages. Apparently
the IBinder can be cached in ActivityManager and onBind() is not
always called when a service is connected the second time.
Test: manual; ensure a service recieves an onsubscribe for an
active rule post requestUnbind/requestRebind
Fixes: 62584038
Change-Id: Iffe37242509f3bf26e609e6b423f3928c00156ad
(cherry picked from commit 265d093cd9)
* changes:
Remove VPN info arrays from NetworkStats(Observer|Recorder)
NetworkStatsFactory: Take VPNs into account for network/battery stats
Remove duplicate line in clat_simple test file
Remove unused lastStats parameter
Revert "Revert "Take all VPN underlying networks into account when migrating traffic for""
Before this CL, the magnifier could deadlock when the following
happened:
1. the renderer is asked to draw (and a frame callback is provided)
2. a #dismiss() happens on the UI thread. This acquires mDestroyLock
(previously line 309)
3. InternalPopupWindow#destroy() is called, and this calls
mRenderer.destroy(). This attempts to destroy the renderer on the UI
thread, however the UI thread will wait until the pending frame callback
corresponding to step 1 is executed on the render thread.
4. The frame callback starts executing on the render thread, and tries
to acquire mDestroyLock (previously line 1093). However, this is held by
the UI thread, so a deadlock happens.
This CL completely removes mDestroyLock, relying on the existing
synchronization between the UI and render threads described in step 3.
Bug: 134584742
Test: manual testing
Change-Id: Ia4c75b5b997e0ed94d5a3814dd4507a8fffa124d
Add known public alternatives or recommendations for greylisted APIs in
Bluetooth.
Bug: 135171386
Test: m
Change-Id: I86e708be37eb7d1b0fafa2d64283b7f81bc02e51
