There are now some new trim memory levels that are sent to
non-background applications as RAM becomes low.
There is a new API for an application to retrieve information
about memory trimming and such on demand.
Fixed various checks against the memory trim level to be
robust (not compare against exact values).
Change-Id: Ifd1c6151124350168aef20a94e517166fd2e03eb
This is especially useful for slow animations such as blinking the
cursor, which only needs to happen after a certain amount of time
has elapsed.
Change-Id: If1163a3480078c75d6461eb8f96d8bf8b625534f
It turns out that terminateHardwareResources can call into destroySurface
to make the current context 0, like in Gmail.
bug:6079959
Change-Id: I07b2f3e91d6276b6c8e1b48f72bc87d28337fe2f
Bugs 6075823, 6050563
Revise pressed state dispatch logic:
Only propagate pressed state to non-clickable views. This should
eliminate the "double glow" problem in some list items where a
clickable child button has a secondary glow along with a clickable
parent. This only applies to setPressed(true) calls; setPressed(false)
must propagate. Don't early-out in setPressed to support this use
case.
Change-Id: Ibbe2309f5030282fad8d23e4a9bc4616b3f5dc7c
Optional titles will only be displayed in the CAB if they entirely fit
instead of ellipsizing.
Fixes bug 5821883
Change-Id: I0cfd6d4fd34a4fa9f520499d577706da30606811
As said in https://android-git.corp.google.com/g/#/c/155992
finishComposingText is indeed too broad of a method.
Introducing a new dedicated method to warn the InputConnection.
Should solve the problems with a negative counter value.
Change-Id: I5525d776916f0c42d5e6d4a4282aed590d7f0e9a
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
1. A bad merge on my part caused ViewRootImpl not to register
for accessibility state change.
bug:6064348
Change-Id: Idf7b8b444e9021e9d9ec3749164cfe448c8268ab
1. AccessibilityNodeInfo were not cloned when cached
and obtained from the cache. This was causing a
problem when the client calls #recycle() as he
should since this results in wiping the data of
the cached node info.
bug:6026952
Change-Id: I5807b09d95ef6f310327192ff91f036adf337e33
1. Before there were two caches one in the app process that
kept track only the ids of infos that were given to a
querying client and one in the querying client that
holds the infos. This design requires precise sync
between the caches. Doing that is somehow complicated
since the app has cache for each window and it has
to intercept all accessibility events from that window
to manage the cache. Each app has to have a cache for
each querying client. This approach would guarantee that
no infos are fetched twice but due to its stateful nature
and the two caches is tricky to implement and adds
unnecessary complexity. Now there is only one cache in
the client and the apps are stateless. The client is
passing flags to the app that are a clue what nodes to
prefetch. This approach may occasionally fetch a node
twice but it is considerably simpler and stateless
from the app perspective - there is only one cache.
Fetching a node more than once does not cause much
overhead compared to the IPC.
Change-Id: Ia02f6fe4f82cff9a9c2e21f4a36747de0f414c6f
