Some of these tables exist in both the amrnb and amrwb libraries,
but with different content.
This avoids some cases of multiple definitions of symbols, if
linking in both libraries statically into the same executable,
if the libraries are built as C. (As C++, the local symbols
get mangled so they don't conflict with the external C symbols
in amrnb, that are unmangled.)
Most of this was committed on the master branch of the opencore
repository in commit 0cd4b3ac412dd0a8370ce339e89cf346c6cfe395,
based on AOSP contribution 10016.
Change-Id: I5387e699ce54a56dc43fcfa0396dee5c99280fd9
This fixes compilation as C - while the source files are named
.cpp, they actually are compileable as pure C (except for this
cast).
This was committed on the master branch of the opencore
repository in commit ae27d9b2ef68c4e6fc383a8cab93d6baa235ff6b,
based on AOSP contribution 10014.
Change-Id: I4f533313be041ad3e0a03ffc5f4207480894ddd1
This avoids warnings about an empty body in an if statement.
mem_free does the same null check, so the accidental extra
semicolon was harmless, and the whole if statement actually
is needless. But if removing the if statements, all the
other ones should be removed too, for consistency.
(This could be done as a separate change).
Change-Id: I1b6064dedd15ffa949043bb5396148aaed9b43f6
The arm specific functions are implemented in .s files,
without any function declarations in headers.
This fixes compiler warnings about implicit declarations
of these functions.
Change-Id: I1512560b6740c1879f378886e05aaad2e3a6c869
Since the Length field is unsigned, the comparison will always
be false. The corresponding code in the aac encoder doesn't have
any check for Length.
This avoids a warning about comparison always being false.
Change-Id: I57c28ff9d09cb9ac4effeaeb40db608ab976acc6
* commit '78fc0c0bfae913a4a44011225396ae525b335fb1':
stagefright amrnb: Properly negate all values
stagefright amrnb: Fix a bug on architectures where long is 64 bit
* commit 'ea227787253e29da2d688399b097e05708d3bf73':
stagefright amrnb: Properly negate all values
stagefright amrnb: Fix a bug on architectures where long is 64 bit
warning: pointer of type 'void *' used in arithmetic
warning: enumeral and non-enumeral type in conditional expression
Change-Id: I7b8d626a636145ef648e3b5d0e77068216dd012e
o also added a check on whether capture rate was set before starting time lapse video recording.
o related-to-bug: 6045507
Change-Id: I8e1fdc8e8931e2684ab3822dc6260db44658e87d
All future releases will use the Chromium HTTP stack and maintaining two HTTP
stacks adds maintenance overhead. The Chromium HTTP stack requires V8, but we
now use V8 in all build targets (b/5495373), so we can safely drop the Android
HTTP stack.
LoadListener, HttpAuthHandlerImpl, Network, SslErrorHandlerImpl, WebViewWorker
- Android-stack specific, removed
StreamLoader, FrameLoader
- Require LoadListener, removed
CacheLoader, ContentLoader, DataLoader, FileLoader
- Extend StreamLoader, removed
BrowserFrame
- Removed methods that create LoadListener
- BrowserFrame.startLoadingResource() is called from native
CallbackProxy, WebView
- Removed calls to Network methods
CacheManager, CookieManager, CookieSyncManager, WebViewCore, WebResourceResponse
- Removed other Android-stack specific code
JniUtlil
- Removed useChromiumHttpStack()
WebViewDatabase
- Removed all code to create cookies and cache databases for Android HTTP stack
See corresponding WebKit change https://android-git.corp.google.com/g/166327.
Bug: 5495616
Change-Id: If491675516f6eb187077af4220214bb6e6a8d045
Get rid of the file cache, since it tends to run out of memory for large
numbers of files. This slows down the scanner somewhat, but recent
optimizations more than make up for that.
With this change, the postscan phase of the media scan now only processes
playlists. Removal of entries for files that no longer exist is done as
part of the prescan.
Lookups in the file cache are replaced by simple queries, which are still
reasonably fast because of a new index recently added to the media provider
database. Note that there was a bug in the case-insensitive matching for
file cache entries, in that e.g. an uppercase a-accent-aigue would be mapped
to its lowercase version, whereas the underlying case-insensitive filesystem
treats them as different characters. Getting rid of the file cache also fixes
this issue.
Bug: 4474617
Change-Id: I39c6f1a35bb518ef7ab912e9b9401663821ef48e
