How to Crash (Almost) Any Android App Through Autofill Framework

Autofill Framework is one of the things that should have resolved lots of issues regarding password managers or other apps that strive in simplifying the process of filling in the data for the user (https://www.xda-developers.com/android-os-autofill-framework-will-finally-resolve-a-long-standing-lag-issue-with-password-managers/). There were even threats by Google itself that apps who are not going to use Autofill Framework instead of Accessibility Service to fill in the data, are going to be kicked out from the Play Store (https://www.xda-developers.com/google-threatening-removal-accessibility-services-play-store/) . About the latter, I think Google went too far given that Autofill Framework being developed for almost two years still has massive issues, such as being able to kill any other Android app.

This framework is being adopted, but so far Autofill Framework does not cover pretty basic use cases. And there is not just not covering, but through Autofill Framework you can crash other apps. I have even created a ticket for that: https://issuetracker.google.com/u/0/issues/125158212 . In my GitHub repository, you can get the code which demonstrates how to use Autofill Framework to crash other Android apps: https://github.com/vaidotasstrazdas/autofill-crash-demo .

The idea is simple – simulation of dataset being no longer available which might happen due to lots of circumstances. For instance, user logs out, and another user logs in which does not have any data that previous user had. As you can see, use case is really valid, often occuring, but such use case crashes the app you want to autofill. Hopefully, Google will fix this bug, or provide another way to make sure this issue is resolved.

new Date() is really new one

I have encountered quite an interesting thing under Java, Also, under Swift, but semantics will go for Java this time.

Does new Date() == new Date()? Well, mostly it would be yes (for the one-liner code at least it would be almost yes!). However, under some circumstances it would not be the case. Read the following (https://docs.oracle.com/javase/7/docs/api/java/util/Date.html): “The class Date represents a specific instant in time, with millisecond precision”. Definitely, it is crystal clear that new Date() represents something for time at any given time. However, this “any given time” is only understandable for Java VM, not for human or some alien. Should it really be this way? Well, in some circumstances I would not think so.

If new Date() !=(sometimes) new Date(), then it should mean that new SomeCustomInterfaceImplementation() !=(somtimes) new SomeCustomInterfaceImplementation(). In other words, you provide no arguments, and you already would get completely undefined behavior. In my opinion, this should not be the case. Why? Because “new” is a keyword, not something that will give you definitely completely different from previous one. Semantically, it may mean that yes, we should treat “new” directly, and object might slightly differ from previous instance. However, there may be lots of thinking, and so on. Still, shouldn’t we be clear about that?

For instance, why do we even bother overriding equals() / hashCode() methods just to make sure that “==” would work in the same way given arguments are completely the same despite any of the circumstances (such as time, and anything like that). In my opinion, time is something that we can’t control, so I think even Java/Swift should not go this way, i.e. trying to give us some real current Date which might be not possible at all even in thousands of years.

Some developers might disagree with me. And I think it is natural. More on that, it would be even greater to hear other developers’ opinion on this matter. But for now, I think that time is another argument for the software that should be specified, since we humans are still not able to tell which time is it exactly given our limitations of our clocks, computers, and so on.