Files
platform-external-webrtc/api
Jorge E. Moreira b6df60492c Generate new Android.bp file and correct build errors
The following are not yet available in their respective libraries so
attempts to use it in webrtc result in a call to abort():
* libvpx's CONSTRAINED_FROM_ABOVE_DROP constant
* libyuv's I010 buffers

The original webrtc project expects to have third party libraries
checked out in third_party/ and base/third_party/. Added some headers
in those directories with a single line including the right header from
external/<library>. Updated .gitignore to keep track of said headers.

Bug: 153469641
Test: mm, also built cuttlefish using this library and ran it locally
Change-Id: I2d596942e34093dccc65d4b7b8249b6afc14d31f
Merged-In: I2d596942e34093dccc65d4b7b8249b6afc14d31f
2020-07-23 13:34:20 -07:00
..
2020-07-21 14:54:49 -07:00
2020-01-21 12:13:11 +00:00
2020-07-21 14:54:49 -07:00
2020-07-21 14:54:49 -07:00
2020-01-21 12:13:11 +00:00
2020-07-21 14:54:49 -07:00
2020-07-21 14:54:49 -07:00
2020-07-21 14:54:49 -07:00
2020-05-08 20:01:03 +00:00
2019-06-03 08:15:09 +00:00
2020-07-21 14:54:49 -07:00
2019-02-01 13:24:47 +00:00

How to write code in the api/ directory

Mostly, just follow the regular style guide, but:

  • Note that api/ code is not exempt from the “.h and .cc files come in pairs” rule, so if you declare something in api/path/to/foo.h, it should be defined in api/path/to/foo.cc.
  • Headers in api/ should, if possible, not #include headers outside api/. It’s not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that we’re trying to shrink.
  • .cc files in api/, on the other hand, are free to #include headers outside api/.

That is, the preferred way for api/ code to access non-api/ code is to call it from a .cc file, so that users of our API headers won’t transitively #include non-public headers.

For headers in api/ that need to refer to non-public types, forward declarations are often a lesser evil than including non-public header files. The usual rules still apply, though.

.cc files in api/ should preferably be kept reasonably small. If a substantial implementation is needed, consider putting it with our non-public code, and just call it from the api/ .cc file.