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
Move in the direction of a more publishable API for configuring a
media player for retransmission. It used to be that we used a custom
invoke and a modified URL (prefixed with aahTX://). There are many
issues with this technique and it was never meant to stand the test of
time.
This CL gets rid of all that. A new (but currently hidden) method was
introduced to the java level MediaPlayer API, called
setRetransmitTarget(InetSocketAddress), which allows an app writer to
set the retransmit target. For now, this method needs to be called
before a call to setDataSource (which is pretty unusual for the
MediaPlayer API) because this mid level code uses this as a cue to
instantiate an aahTX player instead of relying on the data source to
select a player. When retranmit functionality becomes part of the
existing android player implemenation, this
set-retrans-before-set-data-source behavior can go away, along with
the aahTX player itself.
Change-Id: I6ab07d89b2eeb0650e634b8c3b7a0b36aba4e7dd
This reverts commit 64006cb1642b2ec0ee74c66007d869b884391fd1.
Back out this change in order to get ready to implement a longer term,
more media-team approved way of selecting a retransmit player.
Change-Id: I97b68b9859a174eab858598cb00d4445a14fbc17
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
