Adds ignore for all lint errors in Chromium code. Changes minimum SDK for
instrumentation tests to 16 from 14. Adds TargetApi annotations.
BUG=webrtc:6597
Review-Url: https://codereview.webrtc.org/2670473004
Cr-Commit-Position: refs/heads/master@{#16412}
Since we can now have multiple H264 payload type, we need to move all of them to the beginning of the codec list, instead of greedily taking the first payload type that matches the preferred codec name.
BUG=webrtc:6738
Review-Url: https://codereview.webrtc.org/2658573009
Cr-Commit-Position: refs/heads/master@{#16349}
In multi-window mode the non-active activity receives onPause. We
shouldn't stop the camera in this case.
BUG=webrtc:7018
Review-Url: https://codereview.webrtc.org/2648483003
Cr-Commit-Position: refs/heads/master@{#16186}
Previously CallActivity would be leaked on every call. This CL fixes the
problem.
BUG=webrtc:6684
Review-Url: https://codereview.webrtc.org/2640433003
Cr-Commit-Position: refs/heads/master@{#16123}
The test case is put inside a new test target. That test target will be started from a test script to asses video quality.
BUG=webrtc:6545
Review-Url: https://codereview.webrtc.org/2585813002
Cr-Commit-Position: refs/heads/master@{#16088}
Also enable Intel HW Vp8 encoder by default in AppRTCMobile.
BUG=webrtc:6683
Review-Url: https://codereview.webrtc.org/2614373004
Cr-Commit-Position: refs/heads/master@{#16002}
Created a java wrapper for the callback OnAddTrack in this CL since it has been added to native C++ API
The callback function is called when a track is signaled by remote side and a new RtpReceiver is created.
The application can tell when tracks are added to the streams by listening to this callback.
BUG=webrtc:6112
Review-Url: https://codereview.webrtc.org/2513723002
Cr-Commit-Position: refs/heads/master@{#15745}
BUG=webrtc:6649
- Supports Bluetooth Headset profile.
- Detects new BT headset:
+ enabled at start, and
+ powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
- Starts routing audio to BT headset when enabled, i.e, BT is default.
Review-Url: https://codereview.webrtc.org/2501983002
Cr-Commit-Position: refs/heads/master@{#15610}
This improves the performance of SurfaceViewRenderer. This feature is added
behind a flag for now because it can be buggy on some devices.
BUG=webrtc:6470
Review-Url: https://codereview.webrtc.org/2510413002
Cr-Commit-Position: refs/heads/master@{#15181}
Since the class no longer creates its own videoCapturer and it may not
even be a camera, the check doesn't make sense anymore. This also
removes some of the build warnings.
BUG=webrtc:6558
Review-Url: https://codereview.webrtc.org/2434533003
Cr-Commit-Position: refs/heads/master@{#14696}
The old signature of this method has been deprecated. However, the new
signature is only support API level 23+, so we can't really use it yet.
BUG=webrtc:6558
Review-Url: https://codereview.webrtc.org/2437593004
Cr-Commit-Position: refs/heads/master@{#14695}
Reason for revert:
Breaks internal project.
Original issue's description:
> Support for video file instead of camera and output video out to file
>
> When video out to file is enabled the remote video which is recorded is
> not show on screen.
>
> You can use this command line for file input and output:
> monkeyrunner ./webrtc/examples/androidapp/start_loopback_stubbed_camera_saved_video_out.py --devname 02157df28cd47001 --videoin /storage/emulated/0/reference_video_1280x720_30fps.y4m --videoout /storage/emulated/0/output.y4m --videoout_width 1280 --videoout_height 720 --videooutsave /tmp/out.y4m
>
> BUG=webrtc:6545
>
> Committed: https://crrev.com/44666997ca912705f8f96c9bd211e719525a3ccc
> Cr-Commit-Position: refs/heads/master@{#14660}
TBR=magjed@webrtc.org,sakal@webrtc.org,jansson@chromium.org,mandermo@google.com,mandermo@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6545
Review-Url: https://codereview.webrtc.org/2425763003
Cr-Commit-Position: refs/heads/master@{#14664}
When video out to file is enabled the remote video which is recorded is
not show on screen.
You can use this command line for file input and output:
monkeyrunner ./webrtc/examples/androidapp/start_loopback_stubbed_camera_saved_video_out.py --devname 02157df28cd47001 --videoin /storage/emulated/0/reference_video_1280x720_30fps.y4m --videoout /storage/emulated/0/output.y4m --videoout_width 1280 --videoout_height 720 --videooutsave /tmp/out.y4m
BUG=webrtc:6545
Review-Url: https://codereview.webrtc.org/2273573003
Cr-Commit-Position: refs/heads/master@{#14660}
Reason for revert:
Breaks internal project.
Original issue's description:
> Rename AppRTCDemo on Android and iOS to AppRTCMobile
>
> The purpose is to make it clearer it is a mobile application.
>
> BUG=webrtc:6359
> NOPRESUBMIT=true
>
> Committed: https://crrev.com/d3af58bdab5b25acd62cd816363becc7003d3e5a
> Cr-Commit-Position: refs/heads/master@{#14356}
TBR=sakal@webrtc.org,kthelgason@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6359
Review-Url: https://codereview.webrtc.org/2358133003
Cr-Commit-Position: refs/heads/master@{#14358}
The purpose is to make it clearer it is a mobile application.
BUG=webrtc:6359
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/2343403002
Cr-Commit-Position: refs/heads/master@{#14356}
The old method is marked deprecated and will be removed soon. The new
method checks if all cameras on the device support better than legacy
implementation of the camera2 API.
BUG=webrtc:6390
Review-Url: https://codereview.webrtc.org/2354883002
Cr-Commit-Position: refs/heads/master@{#14350}
The Java VideoSource class wraps the C++ AndroidVideoTrackSource.
AndroidVideoTrackSource is the object actually owning the VideoAdapter.
We currently control the VideoAdapter through the Java VideoCapturer,
but it is more natural and direct to control it through the Java
VideoSource class. This CL adds the necessary function to do this, and
the function in VideoCapturer is deprecated.
BUG=webrtc:6391
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2350933006 .
Cr-Commit-Position: refs/heads/master@{#14332}
In Android AppRTC Demo, there was a bug where toggling disable hardware
AGC/NS would not be reflected into the summary of those settings. This
change fixes this issue.
Review-Url: https://codereview.webrtc.org/2184223003
Cr-Commit-Position: refs/heads/master@{#13551}
stack will be removed soon in a separate CL. Constraints will not be supported
in the new implementation. Apps can request a format directly and the closest
supported format will be selected.
Changes needed from the apps:
1. Use the new createVideoSource without constraints.
2. Call startCapture manually.
3. Don't call videoSource.stop/restart, use startCapture/stopCapture instead.
R=magjed@webrtc.orgTBR=kjellander@webrtc.org
Review URL: https://codereview.webrtc.org/2127893002 .
Cr-Commit-Position: refs/heads/master@{#13504}
Add an option to use Camera2 implemantion of CameraVideoCapturer in
AppRTC Android Demo. It is enabled by default.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2077663003
Cr-Commit-Position: refs/heads/master@{#13391}
The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).
The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
- PeerConnectionFactory.startInternalTracingCapture().
I've separated these two methods to make it more clear which of the
parameters controls which system.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2110853003
Cr-Commit-Position: refs/heads/master@{#13334}
not to be created in apprtc on Android.
The path separator was missing when the path for the aecdump
file was created. This CL adds that path separator.
Note that the change of the formatting of the rest of the
line was caused by "git cl format" (the clang automatic
formatting).
BUG=webrtc:5991
Review-Url: https://codereview.webrtc.org/2053263002
Cr-Commit-Position: refs/heads/master@{#13121}
Right now if an exception is thrown, it doesn't seem to be logged
anywhere. This CL makes it show a pop-up with the error message.
This should save time debugging issues.
Review-Url: https://codereview.webrtc.org/2049933004
Cr-Commit-Position: refs/heads/master@{#13120}
Reason for revert:
Updated signature to work with other JNI versions. We would need to compile it differently in order to catch failures like this in WebRTC in the future.
Original issue's description:
> Revert of Android: Add FramerateRange class (patchset #2 id:60001 of https://codereview.webrtc.org/2010763003/ )
>
> Reason for revert:
> Breaks downstream Android tests:
> java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;
>
> We should have a similar test in WebRTC so we can catch such errors pre-commit.
>
> Original issue's description:
> > Android: Add FramerateRange class
> >
> > The Camera1 and Camera2 API use different framerate range types. Camera1
> > uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> > unfortunately only available on Lollipop and later, so this CL adds a
> > similar FramerateRange class in CaptureFormat.
> >
> > The purpose with this CL is to have a common framerate range type that can
> > be reused from both Camera1 and Camera2 in helper functions such as
> > CameraEnumerationAndroid.getClosestSupportedFramerateRange().
> >
> > BUG=webrtc:5519
> > R=sakal@webrtc.org
> >
> > Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> > Cr-Commit-Position: refs/heads/master@{#12942}
>
> TBR=sakal@webrtc.org,magjed@webrtc.org
> NOTRY=True
> BUG=webrtc:5519
>
> Committed: https://crrev.com/bd5621f065fd25e0a77307f10dc9ddaf76e7945f
> Cr-Commit-Position: refs/heads/master@{#12956}
TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2019333002
Cr-Commit-Position: refs/heads/master@{#12957}
Reason for revert:
Breaks downstream Android tests:
java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;
We should have a similar test in WebRTC so we can catch such errors pre-commit.
Original issue's description:
> Android: Add FramerateRange class
>
> The Camera1 and Camera2 API use different framerate range types. Camera1
> uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> unfortunately only available on Lollipop and later, so this CL adds a
> similar FramerateRange class in CaptureFormat.
>
> The purpose with this CL is to have a common framerate range type that can
> be reused from both Camera1 and Camera2 in helper functions such as
> CameraEnumerationAndroid.getClosestSupportedFramerateRange().
>
> BUG=webrtc:5519
> R=sakal@webrtc.org
>
> Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> Cr-Commit-Position: refs/heads/master@{#12942}
TBR=sakal@webrtc.org,magjed@webrtc.org
NOTRY=True
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2024573002
Cr-Commit-Position: refs/heads/master@{#12956}
