Develop Reference

WebRTC - Echo issue in Multiple calls on android devices

I am working on an Android app that allows live chat and call functionality. I am new to WebRTC in android. I am trying to add multiple call functionality using WebRTC. I got success in connecting multiple P2P calls (Upto 6 users are easily gets connected using Mesh Topology.
Here are the steps that I am following:
A => B Call successful ==> Result: audio clear no problem on both the ends
A => C Adding New Caller C from A ==> Result: audio clear no problem on both the ends.
C => B in background C gives call to B and gets accepted on B's end => Result: audio clear no problem on all the ends.
Now, All 3 participants are connected and can communicate easily.
The issue is:
When any of the participants leaves the call, Any of the remaining participants are hearing Echo of their own voice.
All my call related setups are done using RingRTC. Please help if anyone has faced this issue.
I tried setting up Noisce Supressors, AcousticEchoCanceler and other options for each remaining audio sessions as below. But its not helping.
public void enable(int audioSession) {
Logging.d(TAG, "enable(audioSession=" + audioSession + ")");
assertTrue(aec == null);
assertTrue(agc == null);
assertTrue(ns == null);
// Add logging of supported effects but filter out "VoIP effects", i.e.,
// AEC, AEC and NS.
for (Descriptor d : AudioEffect.queryEffects()) {
if (effectTypeIsVoIP(d.type) || DEBUG) {
Logging.d(TAG, "name: " + d.name + ", "
+ "mode: " + d.connectMode + ", "
+ "implementor: " + d.implementor + ", "
+ "UUID: " + d.uuid);
}
}
if (isAcousticEchoCancelerSupported()) {
// Create an AcousticEchoCanceler and attach it to the AudioRecord on
// the specified audio session.
aec = AcousticEchoCanceler.create(audioSession);
if (aec != null) {
boolean enabled = aec.getEnabled();
boolean enable = shouldEnableAec && canUseAcousticEchoCanceler();
if (aec.setEnabled(enable) != AudioEffect.SUCCESS) {
Logging.e(TAG, "Failed to set the AcousticEchoCanceler state");
}
Logging.d(TAG, "AcousticEchoCanceler: was "
+ (enabled ? "enabled" : "disabled")
+ ", enable: " + enable + ", is now: "
+ (aec.getEnabled() ? "enabled" : "disabled"));
} else {
Logging.e(TAG, "Failed to create the AcousticEchoCanceler instance");
}
}
if (isAutomaticGainControlSupported()) {
// Create an AutomaticGainControl and attach it to the AudioRecord on
// the specified audio session.
agc = AutomaticGainControl.create(audioSession);
if (agc != null) {
boolean enabled = agc.getEnabled();
boolean enable = shouldEnableAgc && canUseAutomaticGainControl();
if (agc.setEnabled(enable) != AudioEffect.SUCCESS) {
Logging.e(TAG, "Failed to set the AutomaticGainControl state");
}
Logging.d(TAG, "AutomaticGainControl: was "
+ (enabled ? "enabled" : "disabled")
+ ", enable: " + enable + ", is now: "
+ (agc.getEnabled() ? "enabled" : "disabled"));
} else {
Logging.e(TAG, "Failed to create the AutomaticGainControl instance");
}
}
if (isNoiseSuppressorSupported()) {
// Create an NoiseSuppressor and attach it to the AudioRecord on the
// specified audio session.
ns = NoiseSuppressor.create(audioSession);
if (ns != null) {
boolean enabled = ns.getEnabled();
boolean enable = shouldEnableNs && canUseNoiseSuppressor();
if (ns.setEnabled(enable) != AudioEffect.SUCCESS) {
Logging.e(TAG, "Failed to set the NoiseSuppressor state");
}
Logging.d(TAG, "NoiseSuppressor: was "
+ (enabled ? "enabled" : "disabled")
+ ", enable: " + enable + ", is now: "
+ (ns.getEnabled() ? "enabled" : "disabled"));
} else {
Logging.e(TAG, "Failed to create the NoiseSuppressor instance");
}
}
}

How was the source code of startService() modified to recognize if it was called from background?

Since about Android 9 it throws an IllegalStateException if startService() was called from the background. I see this exception many times in my developer console:
java.lang.IllegalStateException:
at android.app.ContextImpl.startServiceCommon (ContextImpl.java:1666)
at android.app.ContextImpl.startService (ContextImpl.java:1611)
In these cases, Google recommends to call startForegroundService() and within 5 seconds startForeground(), instead. See "Background execution limits".
Anyway, calling startService() from foreground is perfectly ok. Now, I wonder how exactly Android recognizes/decides that an app is in the foreground to not wrongly throwing an IllegalStateException?
I was starting to dig the source code of Android9/10 and comparing it with 8/7 to discover how startService() was modified to recognize if it was called from foreground/background. But I'm convinced that many developers before me did this already, and I would be happy if they'd give an answer.

In AOSP10 (10.0.0_r25):
Server side:
in startServiceLocked from frameworks\base\services\core\java\com\android\server\am\ActiveServices.java:
// Before going further -- if this app is not allowed to start services in the
// background, then at this point we aren't going to let it period.
final int allowed = mAm.getAppStartModeLocked(r.appInfo.uid, r.packageName,
r.appInfo.targetSdkVersion, callingPid, false, false, forcedStandby);
if (allowed != ActivityManager.APP_START_MODE_NORMAL) {
Slog.w(TAG, "Background start not allowed: service "
+ service + " to " + r.shortInstanceName
+ " from pid=" + callingPid + " uid=" + callingUid
+ " pkg=" + callingPackage + " startFg?=" + fgRequired);
......
// This app knows it is in the new model where this operation is not
// allowed, so tell it what has happened.
UidRecord uidRec = mAm.mProcessList.getUidRecordLocked(r.appInfo.uid);
return new ComponentName("?", "app is in background uid " + uidRec);
}
Then in client side:
in ContextImpl.java as your log:
else if (cn.getPackageName().equals("?")) {
throw new IllegalStateException(
"Not allowed to start service " + service + ": " + cn.getClassName());
}

Following this link into Android's soure code we find getAppStartModeLocked():
int getAppStartModeLocked(int uid, String packageName, int packageTargetSdk,
int callingPid, boolean alwaysRestrict, boolean disabledOnly) {
UidRecord uidRec = mActiveUids.get(uid);
if (DEBUG_BACKGROUND_CHECK) Slog.d(TAG, "checkAllowBackground: uid=" + uid + " pkg="
+ packageName + " rec=" + uidRec + " always=" + alwaysRestrict + " idle="
+ (uidRec != null ? uidRec.idle : false));
if (uidRec == null || alwaysRestrict || uidRec.idle) {
boolean ephemeral;
if (uidRec == null) {
ephemeral = getPackageManagerInternalLocked().isPackageEphemeral(
UserHandle.getUserId(uid), packageName);
} else {
ephemeral = uidRec.ephemeral;
}
if (ephemeral) {
// We are hard-core about ephemeral apps not running in the background.
return ActivityManager.APP_START_MODE_DISABLED;
} else {
if (disabledOnly) {
// The caller is only interested in whether app starts are completely
// disabled for the given package (that is, it is an instant app). So
// we don't need to go further, which is all just seeing if we should
// apply a "delayed" mode for a regular app.
return ActivityManager.APP_START_MODE_NORMAL;
}
final int startMode = (alwaysRestrict)
? appRestrictedInBackgroundLocked(uid, packageName, packageTargetSdk)
: appServicesRestrictedInBackgroundLocked(uid, packageName,
packageTargetSdk);
if (DEBUG_BACKGROUND_CHECK) Slog.d(TAG, "checkAllowBackground: uid=" + uid
+ " pkg=" + packageName + " startMode=" + startMode
+ " onwhitelist=" + isOnDeviceIdleWhitelistLocked(uid));
if (startMode == ActivityManager.APP_START_MODE_DELAYED) {
// This is an old app that has been forced into a "compatible as possible"
// mode of background check. To increase compatibility, we will allow other
// foreground apps to cause its services to start.
if (callingPid >= 0) {
ProcessRecord proc;
synchronized (mPidsSelfLocked) {
proc = mPidsSelfLocked.get(callingPid);
}
if (proc != null &&
!ActivityManager.isProcStateBackground(proc.curProcState)) {
// Whoever is instigating this is in the foreground, so we will allow it
// to go through.
return ActivityManager.APP_START_MODE_NORMAL;
}
}
}
return startMode;
}
}
return ActivityManager.APP_START_MODE_NORMAL;
}
And the method appRestrictedInBackgroundLocked() (which is also called from appServicesRestrictedInBackgroundLocked() as fallback) decides about the startMode:
// Unified app-op and target sdk check
int appRestrictedInBackgroundLocked(int uid, String packageName, int packageTargetSdk) {
// Apps that target O+ are always subject to background check
if (packageTargetSdk >= Build.VERSION_CODES.O) {
if (DEBUG_BACKGROUND_CHECK) {
Slog.i(TAG, "App " + uid + "/" + packageName + " targets O+, restricted");
}
return ActivityManager.APP_START_MODE_DELAYED_RIGID;
}
// ...and legacy apps get an AppOp check
int appop = mAppOpsService.noteOperation(AppOpsManager.OP_RUN_IN_BACKGROUND,
uid, packageName);
if (DEBUG_BACKGROUND_CHECK) {
Slog.i(TAG, "Legacy app " + uid + "/" + packageName + " bg appop " + appop);
}
switch (appop) {
case AppOpsManager.MODE_ALLOWED:
return ActivityManager.APP_START_MODE_NORMAL;
case AppOpsManager.MODE_IGNORED:
return ActivityManager.APP_START_MODE_DELAYED;
default:
return ActivityManager.APP_START_MODE_DELAYED_RIGID;
}
}
But the final decision about foreground or background is done in ActivityManager.isProcStateBackground(uidRec.setProcState):
/** #hide Should this process state be considered a background state? */
public static final boolean isProcStateBackground(int procState) {
return procState >= PROCESS_STATE_TRANSIENT_BACKGROUND;
}
So, this section of the first method here gets the current state of foreground or background:
ProcessRecord proc;
synchronized (mPidsSelfLocked) {
proc = mPidsSelfLocked.get(callingPid);
}

When the app is in following case, it will be allowed to started from background.
The app is persistent. Only the prebuilt system app can do this.
The app is not idle. When the app process is in background for a certain time, it will be set idle.
The app is idle but in an whitelist. backgroundWhitelistUid. Only the app with system uid can add apps to this list.

Android Amazon S3 Uploading Crash

I'm trying to figure out what is the cause of this crash when uploading on Amazon S3 bucket.
Log is:
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean com.amazonaws.mobileconnectors.s3.transferutility.TransferService$NetworkInfoReceiver.isNetworkConnected()' on a null object reference
at com.amazonaws.mobileconnectors.s3.transferutility.TransferService.execCommand(TransferService.java:287)
at com.amazonaws.mobileconnectors.s3.transferutility.TransferService$UpdateHandler.handleMessage(TransferService.java:224)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:145)
at android.os.HandlerThread.run(HandlerThread.java:61)
Is there is something wrong on my code?
public AmazonTransferUtility uploadFileToAmazonS3(String data, Date date){
generateTextFileFromString(data, date);
File jsonFile = new File(getDataPath(), textName);
TransferObserver observer = transferUtility.upload(
textBucketName,
mUUID + File.separator + date.getTime() + textName ,
jsonFile
);
mListener.onAsyncStart();
observer.setTransferListener(new TransferListener() {
#Override
public void onStateChanged(int id, TransferState state) {
try {
if (state.toString().equals("COMPLETED")) {
deleteFile(textName);
if (mListener != null) {
JSONObject result = new JSONObject();
result.put("result", state.toString());
mListener.onAsyncSuccess(result);
}
}
else if (state.toString().equals("FAILED") ||
state.toString().equals("UNKNOWN")
){
mListener.onAsyncFail(id, state.toString());
}
else{
Log.i(TAG, "S3 TransferState :" + state.toString());
}
}catch (JSONException e){
Log.e(TAG, e.getLocalizedMessage());
}
}
#Override
public void onProgressChanged(int id, long bytesCurrent, long bytesTotal) {
if (bytesCurrent == bytesTotal){
Log.i(TAG, "Completed");
}
else{
Log.i(TAG, "Current bytes: " + bytesCurrent + " Of bytesTotal : " + bytesTotal);
}
}
#Override
public void onError(int id, Exception ex) {
mListener.onAsyncFail(id,ex.getMessage());
}
});
return this;
}
And if ever how can I catch this error so that my app stop crashing and just cancel my uploading task.
BTW.
That crash is intermittent and ratio is 1 out of 5 successful sync

This doesn't appear to be something you are doing, it's inside the AWS SDK code. The implication of that NPE is a flaky network. It's been reported to Amazon on github (and confirmed in another ticket) and it appears rolling back one version in the SDK (v2.2.13) may help.
That also makes sense given the changes made in 2.2.14, which are related to S3 transfer and the network.
I'd suggest following those tickets (please don't +1). It's reasonable to expect they will fix it within a week.

Here's a workaround until the bug is fixed, just fire this up in your application's onCreate, or well before any upload activity starts:
/**
* work around for a bug:
* http://stackoverflow.com/questions/36587511/android-amazon-s3-uploading-crash
*/
public static void startupTranferServiceEarlyToAvoidBugs(Context context) {
final TransferUtility tu = new TransferUtility(
new AmazonS3Client((AWSCredentials)null),
context);
tu.cancel(Integer.MAX_VALUE - 1);
}
essentially what this does is tell the TransferService to start up and initialize it's member variables so that it doesn't enter the condition where it tries to service commands before it's ready to.

Android: java.lang.NullPointerException

I am currently have a problem with a buzztouch android app I created the error from google play is
NullPointerException
in BT_viewUtilities.updateBackgroundColorsForScreen()
I have narrowed it down to the following code, does anyone see any kind of error in the code. If you need something else please ask, this would fix quite a few apps. Thank you
//updates a screens background colors and image...
public static void updateBackgroundColorsForScreen(final Activity theActivity, final BT_item theScreenData){
BT_debugger.showIt(objectName + ":updateBackgroundColorsForScreen with nickname: \"" + theScreenData.getItemNickname() + "\"");

Either theScreenData or BT_debugger is null.

I have no idea what your code is doing but the fix is simple:
//updates a screens background colors and image...
public static void updateBackgroundColorsForScreen(final Activity theActivity, final BT_item theScreenData){
if(BT_debugger != null && theScreenData != null){
BT_debugger.showIt(objectName + ":updateBackgroundColorsForScreen with nickname: \"" + theScreenData.getItemNickname() + "\"");
} else {
Log.e("YourApp", "Warning null var, command not completed");
}
}
To debug the error you could do:
//updates a screens background colors and image...
public static void updateBackgroundColorsForScreen(final Activity theActivity, final BT_item theScreenData){
if(BT_debugger != null){
if(theScreenData != null){
BT_debugger.showIt(objectName + ":updateBackgroundColorsForScreen with nickname: \"" + theScreenData.getItemNickname() + "\"");
} else {
Log.e("YourApp", "theScreenData was null, command not completed");
}
} else {
Log.e("YourApp", "BT_debugger was null, command not completed");
}
}

I think this is the line that causes null point exception-theScreenData.getItemNickname()

Android apps throw out VM Aborting inside AsyncTask

I am writing Android apps using Eclipse + SDK 8, running at Android 2.2 emulator.
I create an AsyncTask to process lengthy task in background. Below is the code:
public class taskSavingFavourite extends AsyncTask<Void, Void, Integer>
{
#Override
protected Integer doInBackground(Void... arg0)
{
List<MainListClass> mList = new ArrayList<MainListClass>();
String s = null;
int addedCount= 0;
if (mainListSubTabSelectedTab == 0) mList = buildingList;
else mList = storeList;
if (mList == null) return 0;
try
{
for (int i = 0; i < mList.size(); i ++)
{
if (mList.get(i).checked == 1)
{
s = htFavourite.get(mList.get(i).id+"-"+mList.get(i).type);
if (s == null)
{
addedCount ++;
if (!favouriteList.equals(""))
favouriteList = favouriteList + ";";
favouriteList = favouriteList +
mList.get(i).id + "-" + mList.get(i).type + ":" +
mList.get(i).name;
htFavourite.put(mList.get(i).id + "-" + mList.get(i).type,
mList.get(i).name);
mList.get(i).favourite = 1;
}
}
publishProgress();
}
if (addedCount != 0)
{
SharedPreferences settings = getSharedPreferences("MGS_PRIVATE_DATA", 0);
SharedPreferences.Editor editor = settings.edit();
editor.putString("favouriteList", favouriteList);
//Commit the edits!
editor.commit();
}
}
catch (Exception e) {};
return addedCount;
}
}
The problem is: When the mList is large (1000+ items), current Activity will be force closed and back to launcher Activity. I quite confirm it is not crashed because the annoying "Unfortunately the ..." dialog is not coming out.
I check the logcat and when it happens, it always have this message:
12-10 14:10:28.772: D/dalvikvm(976): threadid=9: sending two SIGSTKFLTs to threadid=2 (tid=977) to cause debuggerd dump
12-10 14:10:30.842: D/dalvikvm(976): Sent, pausing to let debuggerd run
12-10 14:10:38.903: D/dalvikvm(976): Continuing 12-10 14:10:38.903: E/dalvikvm(976): **VM aborting***
I am not sure whether this is android bug or I am missing out something.

Alright, I think I found the reason: Never use tight loop inside AsyncTask:DoinBackground.
So I just put Thread.Sleep(1) inside the loop then everything works like a charm. Maybe this will just happen in emulator, not a real device (I just guess).