The jstring "stringValue" was not never freed.
In the case where "str" was NULL the whole cleanup part (see "goto out")
was even skipped.
This patch makes getObjectPropertyValue() behave like
getObjectPropertyList().
Change-Id: I5a7ec3611036f5253a054b00064999bcd1d1c29e
The function android_media_AudioSystem_error_callback from AudioSystem
JNI interface is using FindClass function but does not delete the
reference created by VM in this function.
By doing this call, VM will add a local reference in IndirectRefTable
and it's the caller's job to delete this reference.
By not doing this, everytime this callback is called, a new reference is
added and never deleted.
The effect is crashing the VM running system_server:
E/dalvikvm( 3071): JNI ERROR (app bug): local reference table overflow (max=512)
W/dalvikvm( 3071): JNI local reference table (0x732da288) dump:
W/dalvikvm( 3071): Last 10 entries (of 512):
W/dalvikvm( 3071): 511: 0x42a90008 java.lang.Class<android.os.Parcel>
W/dalvikvm( 3071): 510: 0x4381fd90 android.view.KeyEvent
W/dalvikvm( 3071): 509: 0x439b9808 android.view.KeyEvent
W/dalvikvm( 3071): 508: 0x42d2fe18 java.lang.Class<com.android.server.input.InputManagerService>
W/dalvikvm( 3071): 507: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071): 506: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071): 505: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071): 504: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071): 503: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071): 502: 0x42ad4298 java.lang.Class<android.media.AudioSystem>
W/dalvikvm( 3071): Summary:
W/dalvikvm( 3071): 510 of java.lang.Class (3 unique instances)
W/dalvikvm( 3071): 2 of android.view.KeyEvent (2 unique instances)
E/dalvikvm( 3071): Failed adding to JNI local ref table (has 512 entries)
...
E/dalvikvm( 3071): VM aborting
In this case, PID 3071 is system server.
Change-Id: I0c113eb72256984854d59a3ccef11a8d23f96e79
Signed-off-by: Robert Chiras <robert.chiras@intel.com>
When enabled defer rendering, it will do precache for DrawPathOp.
The paint used for creating PathTask in precache just get the address
of mFilteredPaint of OpenGLRenderer. So for the following defer
operation like DrawTextOp has possibility change the mFilteredPaint
by getPaint while another WorkerThread in PathCache is using the paint
which pointed to the same address of mFilteredPaint to generate bitmap.
As a result, it will generate a wrong bitmap for generateTexture in
PathCache. To fix it, do a copy of paint when creating PathTask.
CRs-Fixed: 664244
Change-Id: I5516f5b143458b88d3573d15b7ebb34f688800c7
PacProcessor relies on libpac from chromium, which is not built
for 64b right now.
(cherry picked from commit f8749200c06a8714ffd46f5e2ec81be57ad4f7f4)
Change-Id: Ic128e17b7437c130df29eeab3293b9c01f01d70b
Synchronize modifications of volume index by VolumeStreamState
class mutex instead of using synchronized methods.
This avoids possible cross deadlock when modifying volume on
two stream types simultaneously and one is slave to the other.
Bug: 13730145.
Change-Id: I13406c71010ce0c2e2f08f660b6101f310396c98
The property ro.hardware.gps can be specifid to allow a single system
image to work with differrent GPS chips. The HAL layer will use it to load
/system/lib/hw/gps.<ro.hardware.gps>.so. Add support to GpsLocationProvider
to use the same property to find /etc/gps.<ro.hardware.gps>.conf, falling
back to /etc/gps.conf if the property is not set or the file is not present.
Change-Id: Ib285c4d28b0d0be5e038a1e61822edd8bc6d97d9
When ResolverActivity is created with a custom list of matching
applications (rList) as in NFC case, and the alwaysUseOption is
set to true, the prferredActivity is not saved even if the user
presses the "always" button.
When a list is provided the variable mBaseResolveList will be
!= null. This will set mOrigResolveList = null.
When an activity is choosen and one of the buttons are pressed
onIntentSelected is called. The first thing this method does
is to check mAdapter.mOrigResolveList != null, however in this
case mOrigResolveList is always null, and the value is not
saved as PreferredActivity.
This problem was introduced in
6d8dfbd8149942f25f2b9643a12f1fb38f3be834.
Change-Id: I9eac41b7861b5e68ad3978af0dc0285f2a34eb88
Check that each package from the setting has
a parsed pkg before we attempt to perform dex-opt
on it. If it doesn't have a parsed package, adjust
the ABI in the settings, but don't perform dexopt.
It will be dexopted later if it's still active
based on the setting.
bug: 15081286
Change-Id: Ifb6d1d5efdc9c59b251731972afa951ad930d05c
