# KingInstaller: sideloading an APK so Android Auto accepts it > KingInstaller is a small Kotlin utility that installs an APK while making the package manager report it as if it came from the Play Store, using a three stage fallback of plain install, Shizuku and root. Its own documentation is blunt about which devices break the middle stage, and the Android Auto rules it depends on are spelled out. **fcaronte/KingInstaller** — Porting of KingInstaller get from GitLab by annexhack - Repository: https://github.com/fcaronte/KingInstaller - Stars: 585 · Forks: 34 - Language: Kotlin - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/fcaronte-kinginstaller ## What the app does: installer identity, not the install itself KingInstaller is a utility designed to install APK files in a way that tricks the system, and Android Auto, into thinking the application originated directly from the official Google Play Store, helping bypass specific app visibility restrictions. The framing in the README is about installing packages as Google Play Store to work around restrictions, and it is useful for Android Auto. So the install itself is not the point. Any file manager can open an APK and hand it to the package installer. What KingInstaller changes is the metadata the package manager records about who installed the app, and that metadata is what Android Auto and some vendor features consult before they will run a sideloaded application. The project is a port of KingInstaller, taken from GitLab by annexhack, and it is written in Kotlin with an interface following the Material 3 design guidelines. It is GPL-3.0 licensed, the releases are 2.3 on 2026-10-03, 2.2 on 2026-10-01 and 2.1 on 2026-09-27, and the last push was on 2026-10-03, so this is actively worked on with a release roughly every two days at the moment. The repository is an ordinary Gradle Android project, with an app directory, an assets directory, a build.gradle, a settings.gradle, the gradle wrapper, a gradle.properties and a local.properties. The presence of signing.properties at the top level is the one file worth flagging, because a release build needs a signing configuration, and a file with that name in a public repository is a thing to look at before you build from it. ## The hybrid architecture: three ways to reach the package manager The feature list describes a hybrid installation architecture that combines direct intents, a remote Shizuku UserService and root execution. The direct intent route is the ordinary path, where the app hands the APK to the system installer. The Shizuku route uses a remote UserService over IPC binding, and the README is specific that it supports four implementations: Shizuku-Next, Standard Shizuku, ShizukuPlus and Plus Drop-In. The root route executes directly through su, which the README describes as granting KingInstaller direct root-level execution via su to manipulate the package manager service directly. On top of that sits the Auto-Fixer, which automatically repairs the installer identity immediately after installation if Shizuku or Root is available. So the spoofing is not only attempted during the install, it is repaired afterwards, which suggests the install itself may succeed with a partially correct identity and need correcting. The Smart Workflow feature is the ordering logic. It is a simplified installation flow recommending the classic method first, falling back to Shizuku, and using Root as the ultimate solution when needed. That ordering is not just a convenience, it is the compatibility advice in the documentation, and it is why the recommended first step involves no switches at all. Two smaller features are worth a mention because they show what the author learned from real devices. There is an App Diagnostic Checker, a built-in tool to inspect how the system perceives an installed application, which is how you tell whether the spoofing actually took effect. And an Android Auto Settings Shortcut, a quick button to jump straight to the Android Auto settings, which is where the rest of the troubleshooting happens. The interface is multilingual and adapts automatically to the user's preferred system language, and the Italian version of the README is kept in parallel with the English one, with the feature list appearing in both. ## The three step workflow, and where it stops working The compatibility section is the most useful part of the README, because it is written as a progressive approach rather than a feature list. Step one is the classic method and it is recommended first. You select your APK and hit Install normally, without enabling any switches. The reasoning given is that on many stock devices and custom ROMs, especially those running Android 10 to 16, the system installer handles the spoofing flags automatically. Step two is the Shizuku trick, used if the classic installation does not flag the app as coming from the Play Store, or if Android Auto rejects it. The recommended implementation is Shizuku-Next by rushiranpise, and the reason is given as a practical one: that fork can start automatically even without Wi-Fi, whereas official Shizuku on unrooted devices usually depends on Wireless debugging, so it often needs a network connection after each reboot. The method is to start Shizuku-Next or another compatible implementation, enable the Shizuku Trick switch in KingInstaller, and try again. The app then uses a secure remote UserService via IPC binding to force the correct installer metadata. Step three is the root method, described as the ultimate fallback for when both the classic method and Shizuku fail due to heavy vendor security restrictions. You enable the Root Trick switch, which grants direct root-level execution via su. And then the specific warning, which is the reason to read this section carefully. On recent Xiaomi, POCO and Redmi devices running MIUI or HyperOS, deep vendor restrictions block standard installation hooks and Shizuku methods. On these devices, Shizuku usually fails, and root access is currently the only reliable method to achieve successful installation spoofing. That is a vendor problem, not a bug in the app, and the documentation is honest about it. It also means the cost of this tool is device-dependent, because the method that works on your phone may require rooting it. ## The Android Auto rule, and why the fields have to be set that way There is a short section on Android Auto rules and insights, based on what the author describes as extensive testing. The Golden Rule is stated as a requirement on two fields. For an app to work in Android Auto, the Requested by field should ideally be the Package Installer, while the Installed by field MUST be the Play Store. The distinction between those two fields is the whole mechanism. Requested by records which component asked the package manager to install the app, and Installed by records the source it was treated as coming from. A sideloaded APK has a Requested by value of whatever installer you used and an Installed by value of something that is not the Play Store, and Android Auto looks at the second one. The first half of the rule is a preference rather than a requirement, and the second half is absolute. The wording difference in the README, should ideally against MUST, is a real distinction rather than emphasis. The second point in that section is a warning about variance. Due to the wide variety of custom ROMs and security patches across manufacturers, certain installation flags or behaviour may require a trial-and-error approach. That is the honest limit of the tool. The spoofing depends on a package manager's internal behaviour, and that behaviour is patched at different rates by different vendors, so there is no combination of switches that works everywhere. The App Diagnostic Checker exists precisely because of this: it tells you what the system currently thinks about an installed app, which is the input you need for the trial and error. The combination of a diagnostic tool, a documented rule about which fields to look at, and an explicit statement that results vary by ROM is a more useful tool than one that claimed to just work. ## The project itself, and what the repository contains The project is small in the way a focused Android utility is, with an app directory holding the code, an assets directory, and the standard Gradle files. Two entries in the top level listing are worth attention. The local.properties file is normally machine specific and holds the path to the Android SDK, and it is present in the repository root rather than ignored, so it may carry a path from the author's machine. The signing.properties file is the more significant one, because that holds the configuration used to sign release builds, and its presence in a public tree deserves a look before you build a release from a checkout. The gradle wrapper and gradle directory are committed, which means the build does not depend on whatever Gradle version happens to be installed, and the gradlew and gradlew.bat scripts cover both Unix and Windows. For support, the README points at a PayPal donation link and a Buy Me a Coffee link. The project also carries a LICENSE file and the README is bilingual, with an English version and an Italian version maintained side by side, the Italian one carrying its own feature list rather than being a translation stub. The Italian feature list is interesting in one respect: it is headed with the version 1.9 in parentheses, while the English list is headed with no version. That suggests the two lists were last synchronised at different points, which is a small piece of evidence about how the project is maintained across two languages. The English one is the one to trust, since it is the more recently updated and the releases are 2.1, 2.2 and 2.3. For a project with releases numbered in the low twos and a release every few days, the maturity question is less about the code and more about how long this technique will keep working against vendor patches, which is exactly what the trial-and-error note concedes. ## Conclusion Adopt KingInstaller if you are sideloading an APK that Android Auto refuses to recognise as Play Store installed, since the app exists to solve exactly that and the documentation sets out each fallback method. Do not adopt it if a normal install already works, because the classic method handles the spoofing flags on many stock devices and custom ROMs running Android 10 to 16, and the escalation to Shizuku or root adds permissions you do not need. Before you reach for the root switch, check whether your device is a Xiaomi, POCO or Redmi, where the documentation says Shizuku usually fails and root is the only reliable method, and read the requested by and installed by rules for Android Auto first. ## FAQ ### What does KingInstaller actually do? It installs APK files in a way that makes the system, and Android Auto, treat the application as if it came directly from the official Google Play Store, helping bypass specific app visibility restrictions. It is a port of KingInstaller taken from GitLab by annexhack. ### What are the three installation methods KingInstaller supports? Direct intents, a remote Shizuku UserService supporting Shizuku-Next, Standard Shizuku, ShizukuPlus and Plus Drop-In, and root execution through su. The workflow recommends the classic method first, falls back to Shizuku and treats root as the ultimate solution. ### Why does KingInstaller not work on Xiaomi, POCO and Redmi devices with Shizuku? On recent Xiaomi, POCO and Redmi devices running MIUI or HyperOS, deep vendor restrictions block standard installation hooks and Shizuku methods. The README states that on these devices Shizuku usually fails and root access is currently the only reliable method. ### What does Android Auto require for an app to be recognised? The Requested by field should ideally be the Package Installer, while the Installed by field MUST be the Play Store. Results can vary between custom ROMs and security patches, so the built-in App Diagnostic Checker is used to inspect how the system perceives an installed application. ### Which Shizuku implementation does KingInstaller recommend? Shizuku-Next by rushiranpise, because that fork can start automatically even without Wi-Fi, whereas official Shizuku on unrooted devices usually depends on Wireless debugging and needs a network connection after each reboot. ## Sources - [fcaronte/KingInstaller on GitHub](https://github.com/fcaronte/KingInstaller) - [Issues](https://github.com/fcaronte/KingInstaller/issues) - [License: GPL-3.0](https://github.com/fcaronte/KingInstaller/blob/master/LICENSE) - [README](https://github.com/fcaronte/KingInstaller/blob/master/README.md) - [Releases](https://github.com/fcaronte/KingInstaller/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fcaronte-kinginstaller