This allows applications to load bitmap in a preferred
target color space, similar to inPreferredConfig for
configurations.
This change also applies recent changes made to BitmapFactory
to BitmapRegionDecoder: support for outColorSpace, inColorSpace
and outConfig.
Bug: 32984164, 36905374
Test: CtsGraphicsTestCase (BitmapColorSpaceTest/BitmapRegionDecoderTest)
Change-Id: I4eded9190d1aa9c7f3033f9bb78a6854cc48a3ef
android.os.VintfObject has two methods:
- report: return device info that can be reported to OTA server
- verify: verify that metadata for a given OTA package is
compatible.
Test: pass
Test: adb shell am instrument -w -e class android.os.VintfObjectTest \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 36814503
Change-Id: Iff8fae289eec8ae9cfc327d0d0d36a1cdd5e6800
If the developer gives some weight/italic to the Typeface.Builder
the fallback used the metadata in the font file. We should use
provided data instead.
This CL also adjusts upper and lower limits on weight, from 100..900 to
1..1000
Bug: 37257745
Bug: 37251569
Test: android.graphics.cts.TypefaceTest passes
Change-Id: I7cf390d96b49afcce359928373698b0c9a9babd8
setFallbackTypeface is returned by Builder.build() method when the
provided font is not loaded due to some reasons.
The fallback family is resolved with width/italic passed to Builder.
Bug: 36794225
Test: android.graphics.cts.TypefaceTest passes
Change-Id: I65e220aca823fd815a52437b11c8e6dc952de8e2
See accompanying frameworks/native commit
"SurfaceFlinger: Add parent-less relative layering" for a full explanation.
Test: Manual of bug repro steps. Plus tests for new SurfaceControl functionality included in frameworks/native.
Bug: 36693738
Change-Id: Ic54598117c1f44a206d33f03d0cc463fbef43fcc
We were previously using exit(1) when code servicing an IPC threw
any subclass of Error. That made it much harder to diagnose cases
where that happened because :
- exit runs global destructors, which might prove problematic (see
linked bug).
- such exits are often due to bugs in application code (things like
AssertionErrors being thrown) but aren't flagged as such by our
infrastructure, or by humans for that matter.
To address both issues, use FatalError() so that the runtime can dump
more useful information to the logs before it aborts.
Test: manual
Bug: 36813403
Change-Id: I5826090229109dc7cb19f0c3571c609f990cd36a
(cherry picked from commit 8143fa57adfbb4a5cc253e4ef68663525a8f81eb)
There is no longer a name size limit to the properties, remove
illegalArgumentException if tag length is too large.
Test: build
Bug: 36696208
Change-Id: I4b4329c8c951082ed0d777cdd70ee3e773bed16c
This gives semantics similar to the start command
queue of services.
The implementation is currently lacking in URI permission
grant handling of the work intents; that will be coming
in a follow-up change.
This includes a first step of adjusting/fixing locking
within JobSchedulerService. The JobServiceContext class
has a bunch of stuff it does that assumes it doesn't need
locking because it schedules the work on a handler. However,
to be able to correctly implement the work finish flow (that
takes care of stopping the job when there is no more work),
we can't dispatch these asynchronously so need to get rid of
that and just do explicit locking.
The switch to explicit locking is half-way there (again the
remaining part will be a follow-on CL). Right now we have
the locking, but still also the handler. But it turns out
there were a number of things we were doing without a lock
held where we actually should have been holding a lock, so
this is better anyway.
Test: new tests added
Change-Id: Iebd098046209b28e60fd2f4d855d7f91cd3a8b03
dalvik-data-code-cache and dalvik-CompilerMetadata should be counted
in JITCache instead of .GC in dumpsys.
Bug: 37224159
Test: adb shell dumpsys meminfo -d
(cherry picked from commit 874c4cf56c0a9ea3b48468a13ec7fb78a3e2594b)
Change-Id: I41def949d91b2fdef0b3f502fe16ae436d058051
There is no longer a name size limit to the properties, remove
illegalArgumentException if tag length is too large.
Test: build
Bug: 36696208
Change-Id: I4b4329c8c951082ed0d777cdd70ee3e773bed16c
dalvik-data-code-cache and dalvik-CompilerMetadata should be counted
in JITCache instead of .GC in dumpsys.
Bug: 37224159
Test: adb shell dumpsys meminfo -d
Change-Id: I2b6051eefb789ad88cfe6e033317583cd0e408b7
"postRawSensitivityBoost" contains the gain value applied after
RAW. Take this value in to account and populate the baseline
exposure accordingly.
Bug: 33623101
Test: runtest -x
cts/tests/camera/src/android/hardware/camera2/cts/DngCreatorTest.java
Change-Id: Ib90a5c1791c422fd36ec44fb6ef695ba8a1dc475
Implement missing color management pieces for bitmaps:
- Bitmap.createBitmap(Bitmap src, ...) now creates a bitmap
in the same color space as the source bitmap
- Bitmap.createScaledBitmap() now creates a bitmap in the
same color space as the source bitmap
- Bitmap.createBitmap(..., ColorSpace colorSpace) to create
bitmaps in a specific color space
- Fix copy from A8 to F16
- Copying bitmaps in F16 or with a color space does not work,
it's currently a limitation in Skia
Bug: 36905374
Test: BitmapColorSpaceTest
Change-Id: I0092fe4432511db50daa3a9393389a9db05e0c2a
libhidl no longer provides a getTransport function. Now, call into the
hwservicemanager which directly interfaces with libvintf.
Test: extensive, see Ia5d1eb41b057ab5d6800f6c3fd22658adecc4be7
Bug: 36377072
Merged-In: I8b0ca845251cd7cd156f3471cbd4b0ce17617be0
Change-Id: I8b0ca845251cd7cd156f3471cbd4b0ce17617be0
(cherry picked from commit f8202e464e09618c2b780d331541f32cc186598e)
The (void*)buffer.get on ARM32 is 4 byte, so the calling convention
will put the argument in [sp, #12]. However, the caller actually
expects a long (the signature of gGraphicBufferClassInfo.builder),
which means it will expect it to be in [sp, #16]
Test: Tested on mtk device
Fixes: 36631082
Fixes: 36974487
Change-Id: I0f723125e612d096c0d76ca3360d895f3f23f286
(cherry picked from commit 98dd5d9a85e8911cf41dea6198d4111f737a5892)
android.display being in the foreground cpuset group is an issue. As
seen on M/S, during heavily CPU load it is not given core 3 even though
it might be free and causes jank. This patch adds the thread to the
top-app group to ensure it is placed on all cores during scheduling
decisions.
Doing this required a couple of changes:
- new API to set per-thread cpusets
- changes to DisplayManagerService to set the thread to top-app group
- changes to SystemServer to set the policy toward the end, as doing it
during start of the DisplayManagerService was in issue (issue being
SystemServer calls setSystemProcess.. -> setProcessGroup which overrides
the group settings for threads in the system server process, including
android.display)
Bug: 36631902
Test: Boot and make sure android.display thread is in the top-app group
Change-Id: Icc394ea0ffcf159d11728ad38de114234a29d20f
Signed-off-by: Joel Fernandes <joelaf@google.com>
(cherry picked from commit 474d311cb098e86c078c3f615e1161e2854f1847)
