Avoid possible memory leaks by ensuring stream closures

Stream close() methods should always be called in finally block
to ensure we don't accidentally leak a stream.

Time to fix some old sloppy code.

Patch Set 2:
 + ensure closure of some other streams
Patch Set 3:
 + missing import java.io.IOException
Patch Set 4:
 + missing import
Patch Set 5:
 + missing ';'
 + whitespace cleanup
Patch Set 6:
 - Reverted changes to MemoryUsage (final requirement
     prevents my implentation)
 + fixed Object allocation in Root.java
Patch Set 7:
 + fixed curly bracket style violations
Patch Set 8:
 x fixed my own sloppy code :/

Change-Id: I3460b558ed5b4489296388c9a52fbb773cefd31f
Tweak "smooth spinners" so small spinner works again and attempt to make horizontal bar smoother

Change-Id: I6bb8c8c3ad3503b3c1e475aba93bf8c226dcd4f0
Performance increase in thumbnail handling

Allow for 160*120 thumbnails which is what cameras commonly
generates. The constants for the micro thumbnail were set to other
values, resulting in recalculations of the thumbnais, which
takes time.

This change only affects the maximum size of the temporary image,
when choosing whether to use the EXIF thumbnail or decoding and
downsampling the full image. Without this change, it will choose
an x16 downsampling of the full image over an x2 downsampling of
the EXIF thumbnail, after the change it will prefer the EXIF
thumbnail.

Cf the DCF specifications at http://www.exif.org/dcf.PDF,
"3.3.6. DCF basic thumbnail data structure, (C) Pixel count"

Tested by running DDMS and measuring the time required to create
a thumbnail. This was 220-280 ms prior to change, < 20 ms after.

Change-Id: I59c753493f947e920bad3fde5eeed5d49d509863
Don't add tint to app icons or custom images
http://gerrit.sudoservers.com/#/c/4663/
SystemUI: more consistent nav tinting behavior
http://gerrit.sudoservers.com/#/c/4905/
Re-use existing thread

Bug: 7377541
Change-Id: I097f2288ebfc2b4a9782cbced19d9c36d0703acb
Reduce jankiness of the transition between a text field with FLAG_NO_FULLSCREEN and a text field with FLAG_NO_EXTRACT_UI

Bug: 7393485

Currently, the extract text view blinks at the transition of InputMethodService.
This change reduces this blinking by making the extract text view invisible when the extract text view is hidden.

Change-Id: I9af96058283a9a5b60707d025ad1abbbbc23c16f
Optimize drawHardwareAccelerated method in Editor class

When inserting a new line or breaking a line,
every display list was invalidated and rebuilt before.
However, we can reuse the display lists above intactly and also
reuse the display lists below with only updating drawing locations.

This patch reuses the display lists if possible.
The display lists above the inserted line are just reused
and the display lists below are reused with only updating
drawing locations not fullly rebuilt.

mIndexOfFirstChangedBlock is the index of the first block
which is moved by inserting or breaking a line.
So the display list whose index is >= mIndexOfFirstChangedBlock
only needs to update its drawing location.

Change-Id: Ica20deb0ebb5750de21356ed31fa9f86e657ff92
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
Fix autorotation sensor loop being reactivated even when off

The sensor loop was reactivated even if turned off after a wake up
=> consider it disabled also if !mEnabled
+ turn debug mode on in case there's another issue.

Since the current autorotation sensor loop is generating 3-4% cpu eating,
we really need a way to turn it off for good for the moment.
System_server now seems to stay at 0.0% cpu with this change & autorotation off on TF101

Change-Id: I5ed3c95809f6d789222819466dacc625ac2d9f1d
Decrease lag generated by autorotation on

There are different issues from what I understand:

1) Discarding of events too close to each others is broken
as mAccelerationTimestampNanos is conditionned by isAccelerating()
on TF101 no events are discarded anymore, and so it creates an update every ~50ms
filing up the android notification message queue quite a bit for nothing and so generating lag.
2) isAccelerating seems incorrect to me too, the code means more that it's accelerating "out of range" and should be discarded in that case.

=> Discard the sample if outOfRange and don't condition the update of mAccelerationTimestampNanos that way next time we come back "too soon"
the sample will be properly discarded.

3) with events being discarded properly on the WindowOrientationListener
the SensorManager can now update every 20ms instead of 50ms
but that is definitely overkill.
=> add SystemProperty sensor.loop.minms with a default value of 50ms to throttle the notifications.
That way the thread sleeps properly instead of sending events as fast as it can.

(increasing up to 100ms can be ok depending if you want faster response or not.)
This can be positionned on a per device prop too.

4) Add 2 SystemProperties:
one on the SystemSensor side: sensor.magnitude.threshold with a default 0 value(doesn't change the behavior)
one on the WindowOrientationListener: orientation.magnitude.threshold with a 200 (0.2G) default value
These allows to discard the sample if it is too close to STANDARD_GRAVITY (ie not accelerating much)
These can be set on a per device or use the default values.
On the TF101 200 works most of the time. But weirdly when docked the reported gravity seems to have an additionnal offsert of -0.2
maybe some magnetic interference from the dock...

For the moment the 0.2G threshold is positionned on the Orientation code.
Once the cpp sensor poll crazy loop is solved it could be better to use the sensor.magnitude.threshold instead.

That should take care of most of the lag generated by autorotation.

PatchSet2: position default SystemProperties values to do nothing.

Change-Id: I093227f539050a6bad8e6e8d9f533eff7bddd0d6
Reduce debugging - PhoneWindowsManager
installd: Delete cache properly for devices using datadata partition

The java side already checks /data/data for free space but installd
still checks /data causing it to never reap the cache (because it
thinks that enough free space is available.)

Change-Id: I736af6ff7ea0c8ae07900168f6b8ac2f7a4dbe0b
Monitor device storage directly in /data/data

The DeviceStorageMonitorService watches over /data, and when things get
full, starts deleting app cached files.  The app caches are actually
under /data/data, which on DINC is its own mount.  This means the
monitor did not notice when app cache grew too big, as it only saw the
size of /data proper.

This patch makes the monitor look at /data/data instead.  For DINC, this
means it can properly manage app cache, but it won't notice if the upper
/data partition is getting full.  That's not as common as /data/data
filling up though.  For the Samsung devices that mount a /datadata and
then symlink to /data/data, it should also work, as statfs dereferences
links first.  For all other devices with only /data, reading statfs on
/data/data still yields the total/free sizes of the /data partition.

Change-Id: I118a85a04c3a257d54d40ce7802426b4e0fe3e87
Audio: Fix abnormal keytone playback during silent mode changing

Change-Id: Icfc4003c9756b3c33578c137e59dc4a2b4f25647
Author: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Ertao Zhao <ertaox.zhao@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 19084 4898
Fix for breakText returning count of glyphs not chars.

Paint.breakText should return the number of characters measured to a given maxWidth, but it returns the number of glyphs instead. The solution loops through the advances and whenever if finds an advance with length bigger than 0 decrements it until reaching zero or the end of the advances. The advance has a zero when a glyphs is for more than on character, for the subsequent characters. The width of the glyphs is added at the first character.

Change-Id: If26fca3a08133d08572dfda1e33536cc0bd8b1e5
MediaScanner: delete abnormal elements in prescan procedure.

There is a race in MediaProvider's mUnmountReciver.
when it doing external storage's database clean up at power down procedure,
if the datebase is big, system may shutdown after db.update, but db.delete
not done, there will be many elements with no filename in the database.
That may cause duplicated files and folders shown in MTP.

This patch clean up these abnormal elements in MediaScanner's prescan procedure.

Change-Id: I0a3dacffd12892b1a2a892b2749a02ab3dea109b
Author: Liang Wang <liangx.wang@intel.com>
Signed-off-by: Liang Wang <liangx.wang@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 58969
Remove unnecessary reference in ActivityManagerService.

Remove referencing mHander in itself. Make message codes simpler.

Change-Id: I996f2805e99297bbc11d8c156560a01017e1ac3c
Disable usage of WAL in DatabaseHelper

According to SQLite documentation, WAL can not be used when database
partition is not accessible for writing (even when the client just
performs read operation).
However, such situation may happen when the partition is full.
As SettingsProvider should always be able to read a value of ANDROID_ID
from corresponding database, this commit disables usage of WAL.
Without this we risk ending up in a situation where /data is full
and the phone is unable to boot properly.

Change-Id: I1f79bbcd8d0f64bf35dc9d7b846bcfb2664d2eac
remove leak WaitResult List in startActivityMayWait

Change-Id: If169ef4474a6a38eb2957c806c6e7f8f7ce67783
Signed-off-by: Young-ho Cha <ganadist@gmail.com>
Framework/base: Added synchronization block to avoid race condition

Fix for the synchronization issue leading to access of an array
Index out of bounds. Issue occurs due to race condition between
removing the activities of a crashed process from history stack
and resuming a separate activity.

Change-Id: I14bb5834e778c15b674248e46fe93b0ce9f37967