If continuous call requestRenderAndNotify before trigger old
callback, old callback will lose, cause VRI will wait for SV's
draw to finish forever not calling finishDraw.
Bug: 253536483
Signed-off-by: Bowen Li <libowen1@xiaomi.corp-partner.google.com>
Change-Id: I8d28ad2bfc077db6343e04d3f454cd06055f9b52
The ArrayEquals, ArrayHashCode, ArrayToString, and
ArraysAsListPrimitiveArray errorprone findings were
demoted from errors to warnings. Fix existing
occurrences of them so they can be made errors again.
Bug: 242630963
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: Ia6f216cc36ad0a5758f39fd9b34962cd4adf9d8e
All the java code used to build the framework jar and run metalava
was previously defined in the toplevel Android.bp files. Move these
into the subdirs where the source actually lives.
This simplifies the rules themselves (no path and needless prefix) and
declutters the top level Android.bp.
Test: m
Change-Id: I97086e309eacb879d16facb8497d9940fa5ddaf6
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
The new annotation to be used is android.compat.annotation.UnsupportedAppUsage.
Test: m
Bug: 145132366
Change-Id: Ib2101605fb385b4f778893e5181a954dccbea037
Exempt-From-Owner-Approval: roll-forward previously approved change
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv \
git diff HEAD^ HEAD | grep '^[+-][^+-]' | grep -v '.import'
Change-Id: I853372f3c6fef905553bb31be4f1bb48df735f7a
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv \
git diff HEAD^ HEAD | grep '^[+-][^+-]' | grep -v '.import'
Change-Id: I087bb1cecbe59f1cf0c2e770c735d7a433722c6f
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
This is partial merge of aosp/Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09. Telephony greylist cleanup has been done separately. Note that annotations outside of frameworks/base/ have been merged from AOSP.
Bug: 137350495
Test: m
Exempt-From-Owner-Approval: merge
Change-Id: I015c466e8b69cc0fed5e9d394ba865aad11d8ba6
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Restrict access to SkBitmap for libandroid_runtime.so to be only within
the boundaries of the graphics module.
Test: CtsUiRenderingTestCases
Bug: 137655431
Change-Id: I4d0ea227e91d22068966513c4e3a55021b9e924f
EGLAttrib is defined for a C / C++ interface and is
intended to be the size of a pointer. That can change
depending on which abi the code is built for but Java doesn't
have a way of dealing with such types. Java defines EGLAttrib
as a jlong, so need to convert jlong to 32bit when running on
a 32bit device.
Bug: 124382141
Test: atest --all-abi CtsGraphicsTestCases:EGL15Test
Change-Id: I966f6a3716b2710e17d10e0d0cb58314853675e0
Test: CtsGraphicsTestCases, CtsUiRenderingTestCases,
CtsRenderscriptTestCases
This is significantly faster than passing the Java object down and then
calling a JNI method to retrieve the pointer. See
https://buganizer.corp.google.com/issues/16656908#comment19
In some cases this changes what used to be native crashes (due to
android::BitmapWrapper:assertValid's LOG_ALWAYS_FATAL_IF) into
NullPointerExceptions (if a caller used a null Bitmap).
In addition:
- Remove unnecessary JNIEnv param from toBitmap(jlong)
- Change instances of toBitmap(JNIEnv*, jobject) to the above
- Replace calls to GraphicsJNI::getSkBitmap() to inline calls to
toBitmap/getSkBitmap
- make Canvas#nInitRaster @FastNative (FIXME: Could these be
@CriticalNative?)
Change-Id: I6194097be1b6e6952eba70e1e7052a5a250eed93
Also change eglCreatePlatformPixmapSurface to throw an
unsupported extension rather than call the native function
which will return an error indicating it's unsupported.
Bug: 80297325
Test: atest CtsGraphicsTestCases:EGL15Test
Change-Id: I94f2d39678515fdacf9b2fccd1c531365930ad1b
For packages:
javax.microedition.khronos.opengles
javax.microedition.khronos.egl
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I3615f60789c14c44284c896c3a9ea291100dff8e
For packages:
android.opengl
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I747cf5d5e6e211dc368545472fee65fd20cdae74
Fixes: 34512969
Test: manual, tested repro in bug and verified
basic GLSurfaceView usage in ApiDemos works
without warnings
Change-Id: I0ce9128874af681e9cfbd3b0b2ef5e2df7080154
SurfaceView needs to notify the window manager that
drawing has been completed, so that animations and such
can begin. Currently this is implemented through
having the SurfaceView user block in surfaceRedrawNeeded
(called from UI thread) until a frame has been completed.
This blocking can be unnecessary serialization during startup, and
also clumsy to implement for some users.
Test: GLSurfaceView and takeSurface API Demos, android.server.cts.SurfaceViewTests
Bug: 31850030
Change-Id: Idda02098a635f25cf392f2d59a3abbe54a1d64d4
This function was never properly supported. It had partial support in our JNI
layer in EGL10 but not implementation in EGL14. It has never been tested and
it is unlikely that drivers support pixmap rendering.
Bug: 11257511
Test: CtsGraphicsTestCases
Change-Id: I209fff470c715cd97148a32b2f41ecf7e5283bab
Fixes: 27071678
It's semi-common for apps to not realize surfaceRedrawNeeded
is a callback they can (and should) be handling, so have it be
more tolerant in lifecycle handling.
Specifically allow a renderer to have not yet been set on
GLSurfaceView, even though it was supposed to have been set already.
Apps are overriding the other lifecycle methods that require this
(created, changed, an destroyed) but not noticing this method.
Change-Id: I6cebca541eeec6e9949bdb55f687b095768a17b2
- For reading into PBOs on GLES3, add an overloaded version of
glReadPixels that takes an offset argument.
Bug 18878609
Change-Id: I744483deab6358a66b0dc5e87be1ae2b96560ac1
- Deprecate the broken version that takes a byte argument.
- Implement a new version that takes a byte buffer argument.
Bug 19478262
Change-Id: I5ea4f11940e93b5964b66dbf5700b7ff8b80339e
It is possible for clients to call SurfaceView
methods e.g. setFormat from the GLSurfaceView#Renderer
drawFrame callback. In this case, SurfaceView#updatewindow
will understand that a redraw is required, and will request
it back to GLSurfaceView. Remember, we are still on the GLThread
though (from the drawFrame callback). So these methods
(requestRenderAndWait, windowSizeChanged), need to be reentrant.
Also fix a data race around mWantRenderNotification, which was
accessed out of lock.
Bug: 26770615
Change-Id: Ic66a36c886ae0b085dd456a4220f0d4f270fb016
GLSurfaceView was not supporting the surfaceRedrawNeeded protocol
which leads to issues with report draw. Thus far this has mostly
been fine as the main surface will not render
a transparent hole until the SurfaceView has finished drawing. However
in the case of SurfaceView replacement the hole in the parent surface
will be preexisting and we must be able to tell that our new SurfaceView
has actually drawn before removing the replacee. This is part of a
series of fixes to 26070641.
Bug: 26070641
Change-Id: Iecc16647f9979aa057449e8bafa540885881ed64
