Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mic detection of audio stops after navigation between activities #692

Open
rckahale opened this issue Oct 15, 2020 · 5 comments
Open

Mic detection of audio stops after navigation between activities #692

rckahale opened this issue Oct 15, 2020 · 5 comments
Labels

Comments

@rckahale
Copy link

rckahale commented Oct 15, 2020

Firstly, very useful & wonderfully easy to implement library.

Overview

My issue is that, I land up in a state where the audio record permission is enabled but audio is not detected.

If I just remain on one activity the issue is not present.
I navigate between 4 activities in which

  1. I ask for audio record permission..navigate to another listing activity..do stuff
  2. I ask for file record permission..navigate to new listing activity..do stuff
  3. I ask for audio record permission....do stuff
  4. I produce sounds using midi & android.media.MediaPlayer

The issue was more often when I had wrongly put the permission asking function inside onResume()
Now I have corrected it & put it inside onStart and the corresponding activities work fine
Issue does not have fixed steps to reproduce.

Expected

  • Mic remains active when app has permission of AudioRecord

Actual

I feel there is an extra call made from onStart whenever I come Back from listing activity or activities which are not using audio record permission. So just like it happened in case of onResume, it stops recording altogether, even if it has permissions.

All audio rec activities are affected and none work till there is killing of app.
If I modify the permission from settings (from enable to disable), in stuck state, the permission enabler does its job and app doesn't need killing

Environment

  • Which library version are you using?
    implementation "org.permissionsdispatcher:permissionsdispatcher:4.7.0"
    kapt "org.permissionsdispatcher:permissionsdispatcher-processor:4.7.0"
  • On which devices do you observe the issue?
    Android Version: 9, Device: Honor9N (Huawei LLD-AL20)

  • Note any other information that might be useful

There are no crashes in the log, but these lines

D/AudioRecordPermission: AudioRecordPermission
I/AudioRecordPermission: remindWithResult:false

I/HwAudioRecordImpl: HwAudioRecordImpl
    sendStateChangedIntent, state=3
D/ZrHung.AppEyeUiProbe: notify runnable to start.
I/Window: window add KeepScreenOnFlag for com.***
I/HwPhoneWindow: updateLayoutParamsColor true mSpecialSet=false, mForcedNavigationBarColor=true, navigationBarColor=ff1f2025, mNavBarShow=false, mIsFloating=false
D/OpenGLRenderer:   HWUI Binary is  enabled

I have read 10 years back there was need to call recordInstance.release() in onStop or onDestroy
https://stackoverflow.com/questions/4342482/cannot-access-audiorecorder

  override fun onStart() {
        super.onStart()
        onAudioPermitWithPermissionCheck() 
    }

 @NeedsPermission(Manifest.permission.RECORD_AUDIO)
    fun onAudioPermit() {
	// stuff
	}
	

Additional info:
There may be some flaw in my implementation as I do not get Allow/Deny popup after its shown once in respective activities after app install. Rest all times, the OnShowRationale is called. But, flow proceeds and works.

@hotchemi
Copy link
Member

@rckahale sorry for the late(somehow missed notification). well I'm now trying to figure out the situation but could I ask the following:

  • if you call onAudioPermitWithPermissionCheck in onCreate how's the situation?
  • Could we get a simple example which we can reproduce the issue if possible?

@rckahale
Copy link
Author

rckahale commented Oct 22, 2020

When I put it in onCreate, its working as expected and above issue does not occur

But, there is a presence of different issue in this scenario

If user has stopped the mic permission from settings, or if user has denied more than once the OnShowRationale associated function is called. This function opens settings (through alert dialog) in a new activity

      val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS)
        val uri: Uri = Uri.fromParts("package", thisActivity.getPackageName(), null)
        intent.data = uri
        intent.setFlags(Intent.FLAG_ACTIVITY_NO_HISTORY)
        thisActivity.startActivityForResult(intent, 123)

When user allows the permission from this settings activity, the user lands back inside the activity where audio work is being done and the function onAudioPermit is not called. (It gets called inside onStart or onResume)

@NeedsPermission(Manifest.permission.RECORD_AUDIO)
    fun onAudioPermit() 

So the activity is in a state as good as audio permissions not granted, which is fixed only when user navigates out and back to this activity

@hotchemi
Copy link
Member

thx, um..I'm just wondering it's kind of a bug originated from Android permission API itself(because our lib is just a wrapper around there and we don't intercept any special procedure)🤔 Perhaps I have not been able to 100% caught up but would you mind trying out without PermissionsDispatcher? 🙏

@rckahale
Copy link
Author

Haha...PermissionDispatcher has landed me into the comfort zone, that now its difficult to write code without it.
Instead I have added, the check of coming from ACTION_APPLICATION_DETAILS_SETTINGS

public override fun onActivityResult(comingFrom: Int, paramInt2: Int, paramIntent: Intent?) {
     if (comingFrom== NO_REC_PERMISSION_CODE) {
            // since there was a need to open permission settings, call the permit flow in case the permission is just now granted
            onAudioPermitWithPermissionCheck()
        }
}

NO_REC_PERMISSION_CODE = 123

This works for now. 👍

@hotchemi
Copy link
Member

glad to hear that haha.

well let me walk through the issue again and JFYI we now have https://github.com/permissions-dispatcher/PermissionsDispatcher/tree/master/ktx which does not rely on kapt anymore and might be easier for debug as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants