The pool management APIs were simplified and using them requires much less
code than implementing your own pooling. Using common pooling logic is
also less error prone. This change swithces AccessibilityEvent and
AccessibilityNodeInfo to the new APIs.
Change-Id: I2dcfe2e1b0b0be5f89bd92359766ae3d6f8a143b
Before to implement a pool of objects, the pooled class had to implement an
interface which was leaking the pool management APIs. This requires
hiding APIs - inconvenient at best. Further, each client had to
implement the chaining of pooled instances which means adding a couple
of member variables which are manipulated by the implemented interface
methods. As a consequence the client is aware of how pooling is
implemented which is error prone and breaks encapsulation. Now the
pool objects are responsible for managing pooling state via reusable
wrapper objects and the clients are oblivious of how pooling is done.
Creating a thin cached wrapper for each pooled object has minimal
performance impact while making the code more maintainable. Actually
implementing of the old version of the APIs was taking as much code
as implementing the pooling yourself.
Also clients had to implement a poolable manager whose responsibility
was to create new instances and provide callbacks when an instance
is added to or removed from the pool. Now, the clinet class should
create a static member for the pool and expose obtain/aquire and
release/recycle methods in which it should create a new instance if
the pool did not return one and clear the state of the host when
it is returned to the pool. Updated the JavaDoc with a best practice.
The pooling was composed of several interfaces and classes scattered
over a few files, now all this is in a single small file.
Update all usages of the pooling APIs in the framework.
Also one had to write a poolable
manager which
Change-Id: Ib8dc286040eb3d7cb7d9668ba76fead05cb97647
Bug #7480719
This change also adds the alias "color" for the attribute "fgcolor".
This change also unifies HTML colors parsing between the Html class
and StringBlock for consistency.
Change-Id: I696a6e080387901d88e9baf7cb989b892f14b9db
This sequence of operations would prevent the background from
changing:
setBackgroundResource(R.something)
setBackgroundColor(aColor)
setBackgroundResource(R.something)
The last call would be no-oped.
Change-Id: I436a33599c88e35f6f36bdd63e9c256c9219e052
FindBugs description:
There is an apparent recursive loop at IntProperty.java
in method set(Object, Integer)
This method unconditionally invokes itself. This would seem
to indicate an infinite recursive loop that will result in a stack overflow.
Note: Checked into AOSP. Cherry-picking for mr1.1.
Issue #7621806 IntProperty has infinite recursion bug
Change-Id: I2f52dd3689198cb948925aa65dd9c95be7888fe7
In alarm manager, print a summary of the top 10 alarms by time
being executed. Keep track of execution time (and wake count) of
each type of alarm for each application so this can be printed in
the summary (and used to compute the top 10 alarms). Rework how
the alarm summary stats are tracked so that we don't need to hold
on to the full Intent for each stat and can get the Intent information
at the time the alarm is sent rather than waiting for whatever Intent
comes back in the result.
Also in the battery stats: sort the kernel wake locks by time, add
a new section showing all partial wake locks across all applications
sorted by time.
Finally a new LocalLog class that is used by AlarmManager to log
important warning messages, so these can also be later found in
its dumpsys output.
Change-Id: Icc07810053e60fb623a49937e696819cb8352b06
TTS input limit is now publicly available from getMaxSpeechInputLength()
static method.
Bug: 7456118
Change-Id: Ib2afbb7202ad9dc15895f322fbd1480a5f1f7278
