Karumi / Dexter

Android library that simplifies the process of requesting permissions at runtime.
http://karumi.com
Apache License 2.0
5.23k stars 670 forks source link

Dexter creates a new entry in Overview #143

Open ivannarino opened 7 years ago

ivannarino commented 7 years ago

Expected behaviour

My app should only have one entry in "Overview" mode (recent apps).

Actual behaviour

When the permission dialog is accepted, it adds a new entry in the "overview", in addition to the main one

Steps to reproduce

Call this when permission is not yet accepted

            Dexter.withActivity(mActivity)
                    .withPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE)
                    .withListener(mPermissionListener).check();

Version of the library

4.1.0

Tested on Samsung Galaxy S6, running Android 6.0.1 and 7.0.0

The new task created is :

TASK com.mycompany.product id=553
  ACTIVITY com.mycompany.product/com.karumi.dexter.DexterActivity 3eeac6 pid=28278
    Local Activity a2ed9a8 State:
      mResumed=false mStopped=true mFinished=false
      mChangingConfigurations=false
      mCurrentConfig={0 1.0 themeSeq = 0 showBtnBg = 0 ?mcc?mnc fr_FR ldltr sw360dp w360dp h616dp 640dpi nrml long port finger -keyb/v/h -nav/h mkbd/h s.5}
      overrideConfig={0 1.0 themeSeq = 0 showBtnBg = -1 ?mcc?mnc ?locale ?layoutDir ?swdp ?wdp ?hdp ?density ?lsize ?long ?orien ?uimode ?night ?touch ?keyb/?/? ?nav/? mkbd/?}
      DisplayMetrics=DisplayMetrics{density=4.0, width=1440, height=2560, scaledDensity=4.0, xdpi=580.571, ydpi=580.571}
      mMultiWindowStyle=MultiWindowStyle{type=0, zone=ZONE_UNKNOWN, option=0x01000002, bounds=null, isNull=false, isolatedCenterPoint=Point(0, 0), scale=0.0, specificTaskId=-1}
      mStackBounds=Rect(0, 0 - 1440, 2560)
      mLoadersStarted=true
      FragmentManager misc state:
        mHost=android.app.Activity$HostCallbacks@fdae9d4
        mContainer=android.app.Activity$HostCallbacks@fdae9d4
        mCurState=3 mStateSaved=true mDestroyed=false
    ViewRoot:
      mAdded=true mRemoved=false
      mConsumeBatchedInputScheduled=false
      mConsumeBatchedInputImmediatelyScheduled=false
      mPendingInputEventCount=0
      mProcessInputEventsScheduled=false
      mTraversalScheduled=false
      android.view.ViewRootImpl$NativePreImeInputStage: mQueueLength=0
      android.view.ViewRootImpl$ImeInputStage: mQueueLength=0
      android.view.ViewRootImpl$NativePostImeInputStage: mQueueLength=0
    Choreographer:
      mFrameScheduled=false
      mLastFrameTime=11385818 (40805 ms ago)
    View Hierarchy:
      com.android.internal.policy.MultiPhoneWindow$MultiPhoneDecorView{218a44a I.E...... R.....I. 0,0-0,0}
        android.widget.FrameLayout{16c577d V.E...... ......I. 0,0-0,0 #1020403 android:id/windowContentFrame}
          android.widget.LinearLayout{5778672 V.E...... ......I. 0,0-0,0}
            android.view.ViewStub{d072ac3 G.E...... ......I. 0,0-0,0 #102046a android:id/action_mode_bar_stub}
            android.widget.FrameLayout{e6cf40 V.E...... ......I. 0,0-0,0 #1020002 android:id/content}
    Looper (main, tid 1) {ebee79}
      (Total messages: 0, polling=false, quitting=false)
pedrovgs commented 7 years ago

This is going to be fun to fix 😃 @nex0s do you have a fix for this? Right now I'm not sure if there is an Android API to don't show this view in the background apps history.

ivannarino commented 7 years ago

Not really, I am going to do some tests.

ivannarino commented 7 years ago

I don't know why, but on some devices the DexterActivity is not finished. I used 'Activity Manager State' to check if the activity was still alive after accepting the permission. On the Nexus 5X 7.1.1 emulator, the DexterActivity is finished correctly.

One dirty workaround would be to add

android:excludeFromRecents="true"

on .DexterActivity

Serchinastico commented 7 years ago

If we set android:excludeFromRecents to true then we won't be able to open the activity if we close it while the permissions dialog is open and that'd be a huge problem.

I'm trying to reproduce the issue in my Nexus 5X but I haven't been able so far.

ultraon commented 7 years ago

Hello everyone, i've bumped with the same issue, and via recents i even can return to the underlying activity and close it via click back :-) It is a very bad behavior. For my side i can fix it with following strings in my manifest:

<activity tools:node="replace" android:name="com.karumi.dexter.DexterActivity" android:theme="@style/Theme.Transparent" />

The issue is in attribute (in Dexter library)

android:launchMode="singleInstance"

According to the doc: https://developer.android.com/guide/topics/manifest/activity-element.html , the launchMode "singleInstance" is always started with new task. In my fix i use default (standard) launchMode.

ka05 commented 7 years ago

I am also experiencing this issue. Has anyone found a fix yet? ( EDIT: @ultraon's Solution worked for me. would be nice not to have to override the activity declaration in the manifest to fix this though.)

EmmettWilson commented 7 years ago

Our app is experiencing issues with this as well. Having the dialog in a new task eliminates the idea of it being modal. The user can swipe that task away without interacting with the dialog. So we never get the callbacks for accept or decline.

ka05 commented 7 years ago

@EmmettWilson I would suggest using @ultraon 's solution for the time being.

EmmettWilson commented 7 years ago

We found this when testing an upgrade from 2.3.1 and went ahead and blocked our upgrade of the library for our project until this is resolved.

EmmettWilson commented 7 years ago

As I started looking into how to fix this I found several other issues surrounding interactions with the back stack. @pedrovgs @Serchinastico Do you want me to enumerate them here, in separate issues, or just explain in a pull request? The best way to describe really is a video.

Serchinastico commented 7 years ago

Hi @EmmettWilson

We prefer to have separate issues for every problem but if you already have a PR in your pocket to solve them together just do whatever takes you less time/effort.

ivannarino commented 7 years ago

@Serchinastico it works perfectly (see my comment on your PR) :+1: