Accessibility-based autofill service not working on Android O beta?

jchw
jchw
Community Member

Hi.

First of all, apologies for the off-topic but thank you for 1password accounts. This finally sold me, I've been dying to get off of a certain competitor, not naming any names but let's just say the last three letters of their name describes my feelings about them right now :)

Anyway, I'm on an unrooted Google Pixel with their Android O beta and using the 1password beta, and it seems the autofill service is not actually triggering. $COMPETITOR also implements the same strategy for autofill and works perfectly fine on Android O beta and Android 7 as well. Sadly, I didn't test Android 7 with 1password, so I don't know if that's what's breaking this.

Android version (8.0)
Accessibility services page with 1password enabled

I understand if the answer is "tough luck." The app does not work flawlessly on my device as-is, but this is the only major breakage I've seen so far, so I figured it was worth asking. (In case you were wondering, the other issue I have is that sometimes coming into the app with my fingerprint, I get thrown to a white page, have to back out and try again to actually get in. Not really sure why.)


1Password Version: 6.5.1.BETA-1
Extension Version: Not Provided
OS Version: Android 8.0.0 beta
Sync Type: 1password Account
Referrer: forum-search:autofill

Comments

  • Hey @jchw. First off, thanks so much for making the switch. And for making my day with that joke. :lol:

    We do have plans to support Autofill in Android O, and while O itself is in beta, we haven't yet released a beta version of 1Password with that support. The team has been hard at work on this for a while, and we are hoping to have some good news to share in the not too distant future. I can't given any ETAs, but we'll definitely let you know when we have something to share. ;)

    As to the Fingerprint Unlock issue, does the same happen if you unlock with a PIN code or your Master Password?

  • jchw
    jchw
    Community Member
    edited July 2017

    Ah, sorry, I have misunderstood. I assumed the accessibility service was a standalone autofill system, it's obviously not, it just compliments the keyboard. I was confused when I noticed 1password wasn't running in the background constantly, which made me think it was a bug, since a couple other password managers use accessibility hooks to implement something a bit like the new autofill API (albeit in a much hackier way.)

    Now onto the actual bug...

    I've collected a bit of data. First of all, triggering it is somewhat tricky because it seems to be a bit probabilistic, but there's a lot of ways you can't trigger it, which might be useful knowledge. In order to explore the exact behavior, I've collected a bit of data on when the bug occurs:

    1password -> Home -> 1password (via Home)
    good : IIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    blank: IIIIIIIIIIIIIIIIIIIIIIIIIII
    
    1password -> Discord (via Switcher) -> 1password (via Switcher)
    good : IIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    blank:
    
    1password -> Home -> Discord (via Home) -> 1password (via Switcher)
    good : IIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    blank:
    
    1password -> screen off -> 1password
    good : IIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    blank: 
    
    1password -> Home -> Discord (via Home) -> Home -> 1password (via Home)
    good : IIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    blank:
    

    (Each I is a single attempt.)

    So, it seems to occur only when hitting home and going directly back into 1password, or at least that's the only trigger that I can truly confirm. It does not seem to matter how much time has passed since leaving the application. Turning off the screen will also revive it.

    The animation for opening the vault plays correctly all the time as far as I can tell, it will just open to a plainly blank screen.

    Also notable: the app is still functional. It's just not possible to see. If I click around and hit a menu or a password, it will start displaying things properly.

    When in this blank state, the app still prevents screenshotting.

    I tried the experiment using master password unlock and it had no practical change. I assume PIN lock would probably have the same effect.

    In fact, I just tried it with "Lock on Exit" off and it still exhibits the same behavior. So, rapidly hitting home and going back into 1password will, around 50% of the time, yield a blank screen, no unlocking involved.

    And one final realization: It does not seem to happen if you switch back into the app using Switcher, only when you hit the icon on Home.

    There may be other more complicated ways to trigger this - I certainly feel like I may have hit it a few times when switching around. I'll make note of if I notice it happen in a way that I haven't already noted.

  • peri
    edited July 2017

    Thanks so much for the detailed report, @jchw. I was able to reproduce this on my 5X with Android O beta and I've created an issue internally for our devs to review.

    Let us know if you need anything else!

    ref: OPA-1186

  • AGAlumB
    AGAlumB
    1Password Alumni

    @jchw: I just wanted to let you know that we've added preliminary support for Google's new Android O filling APIs in the latest betas. Hopefully it won't be far off that everyone gets it once we're finished testing things. And you're welcome to join the beta as well if you like. Cheers! :)

  • @jchw Thanks for providing such a detailed analysis of the issue. I first encountered this issue while testing 1Password with the developer preview. It then appeared that we had fixed it as a side-effect of some changes that we had made while developing version 6.6. I had thought and hoped that would be the end of the issue, but unfortunately it seems to have reared its ugly head again.

    We're currently looking into this and hope to have a fix for it soon. We've got some theories about what may be causing the issue, but it would be helpful to be able to reproduce it consistently (or at least more consistently). At the moment, I'm not able to reproduce it with anything close to the frequency that you reported above. Could you tell me if you're still able to reproduce the issue at this rate? If so, could you provide me with the detailed steps that you're following to do so?

This discussion has been closed.