SomeHiddenMethod.invoke( null, "some important string") Val someHiddenMethod = someHiddenClass.getMethod( "someHiddenMethod", String:: class. Normally, if you wanted to call a hidden method, you'd do something like this (this is in Kotlin, but Java is similar): val someHiddenClass = Class.forName( "") Now, here's where it gets a little weird. The API blacklist blocks the use of reflection, but it doesn't block the use of double-reflection. Like I said in that paragraph, reflection used to be a way to access non-SDK functions. In Java, reflection is a way to access normally inaccessible classes, methods, and fields. If you don't know what reflection is, I recommend reading this page, but here's a quick summary. As of November 1, 2019, all app updates to the Play Store must target API 28 or later.Ĭast your mind back to seven paragraphs ago when I mentioned reflection. Unfortunately, with Google's minimum API requirements for publishing on the Play Store, it would only be possible to target API 27 for so long. The first was to simply keep your app targeting API 27 (Android 8.1), since the blacklist only applied to apps targeting the latest API. Now, there were a few ways to work around the blacklist. Not only did it break quite a bit of Navigation Gestures, but since hidden functions are blacklisted by default (Google has to manually whitelist some per-release), I had a lot of trouble getting Widget Drawer to work. At least for me, this blacklist was pretty annoying. The first beta would warn you when your app used a blacklisted function. When the first beta was released, it was announced that most (not all) hidden functions were no longer available for use to app developers.
#APPTRENDS BYPASS ANDROID#
With Android P, Google decided that just hiding them wasn't enough. Using them requires reflection or a modified SDK. Normally, if you try to use a hidden method or class in an app, it'll fail to compile. If you're wondering why I've been using the word "hidden," it's because these functions aren't even part of the SDK. Even in different versions of AOSP, you never know if a hidden function will still exist or work how it used to. Manufacturers can change or completely remove these hidden functions. Google doesn't guarantee that the rest of the framework will stay consistent. Google can't make sure every single part of the framework works on every single device it approves, so more important methods are selected to be verified. You might be thinking: "Why not just make these non-SDK functions part of the SDK?" Well, the problem is that their operation isn't fully predictable. For instance, my Widget Drawer app makes use of a non-SDK function to detect when a user launches an app from a widget so the drawer can automatically close. These "hidden" parts can be incredibly useful for more hacky or low-level stuff.
0 kommentar(er)
