We use the devsite tool to stage reference docs for review (to
go/dac-stage). That tool is currently broken, because it's expecting
to find a _reference-head-tags.html file which currently exists in
Piper but not in Gerrit. Copying that file into Gerrit lets us
build the Javadocs and stage them. (Files in p/f/b/docs don't
generally affect anything outside of the doc builds.)
Tested by building docs and staging Adapter.html to:
go/dac-stage/reference/android/widget/Adapter.html
Test: make ds-docs
Bug: 71717397
Change-Id: I05430f2d9f23e62b4423b2d6f304c4be1c43b880
- Move camera reference doc images to /reference/images
- Minor formatting changes due to merging SDK/NDK metadata definitions
- Minor wording changes for the same
Bug: 69175492
Bug: 29102963
Bug: 33262893
Test: Build and manual inspection of generated docs diff
Change-Id: Ieaf0c1943eba378cc94a22d184734602c40e25e7
Previously deleted almost all the docs (with CL http://ag/1970807),
since those docs are now managed and staged/published from Piper.
However, reference docs are still generated in Gerrit, so it's useful
to be able to stage those docs from a Gerrit client--and that was
broken by my change, since the staging tool expects to see
_book.yaml and _project.yaml in the reference doc directory. So,
restoring those files to re-enable staging of reference docs from
Gerrit.
The publish process is *not* changed: we still grab a good build
from the appropriate Gerrit branch and migrate those files into
Piper, then publish the Piper files.
Test: make ds-docs ; devsite stage --site=android en/reference
Change-Id: I392f1699dc68767d1ac9b7113a149062e5e48ef7
It tooks 10 years, but better late than never!
Bug: 32984164
Test: Compiled documentation and checked in Chrome
Change-Id: I6dfd7fba6d3077f8c774b203589083bdbc15f9d2
Original Change-Id: I5331cdc968be817ff70ba32dd03fce76493a6ab8
Test: make ds-docs
Android developer docs are now maintained in Piper, go/dac-source
Removing all files from Gerrit, since these files can cause build
errors if they refer to classes that are later removed (whence
bug b/35849713 ).
Gerrit already has readme files in these directories telling people
docs are not maintained here; these readmes will be a lot easier to
spot now.
Ran a doc build with these files deleted, and it seems to work fine,
so submitting this CL *shouldn't* break anything.
Bug: 35849713
Change-Id: Ic74c3f97f9620daf23543930a8b7ed1386f4d172
This configuration uses 64 bits per pixel. Heach component is stored as a
half precision float value (16 bits). Half floats can be decoded/encoded
using android.util.Half.
RGBA_F16 bitmaps are used to decode wide-gamut images stored in 16 bit
formats (PNG 16 bit for instance). aapt is currently not aware of PNG
16 bits so such files must be placed in raw/ resource directories.
This first pass provides only partial drawing support with hardware
acceleration. RGBA_F16 bitmaps are stored in linear space and need
to be encoded to gamma space with the appropriate OETF to be rendered
properly on Android's current surfaces. They are however suitable for
linear blending. Full rendering support will be provided in a future
CL (BitmapShaders might be a bit tricky to handle properly during
shader generation).
Bug: 32984164
Test: bit CtsGraphicsTestCases:android.graphics.cts.BitmapRGBAF16Test
Change-Id: I328e6b567441a1b9d152a3e7be944a2cf63193bd
