ShizuCoreFetch: a Shizuku-based app hub for Android package management
An advanced centralized platform for fetching and managing applications requiring core permissions.
At a glance
- What is it?
- ShizuCoreFetch is a Kotlin app that uses Shizuku's Binder API to install, uninstall and update packages without root. The README documents the workflow and the architecture, but not much about failure handling.
- Who is it for?
- ShizuCoreFetch suits Android users who already run Shizuku and want a single place to install and update APKs without granting root. It is the wrong tool for anyone unwilling to run the Shizuku service, or for devices where Shizuku cannot be started.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 4, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What ShizuCoreFetch does and who it is for
ShizuCoreFetch is an Android application that manages packages at the system level through Shizuku. The README describes it as "an advanced, Shizuku-powered application hub for Android" that lets you "fetch, manage, and silently update your apps with system-level privileges." The target user is someone who already runs Shizuku, either through root or wireless ADB, and wants to install, uninstall or update APKs without the usual confirmation dialogs.
The problem it addresses is concrete. On modern Android, the package manager refuses silent installs to ordinary apps. Shizuku exposes a Binder interface to the system server, and ShizuCoreFetch uses that interface to send the privileged commands. The app itself runs without root, which the README notes makes it "safe and compliant with modern Android security policies." That is the same mechanism other Shizuku clients use, so the interesting part is not the privilege model but what the app layers on top: a browsing and download front end for APKs, described as a store, plus local storage for downloaded files.
It is not a general-purpose package manager for every Android user. It assumes Shizuku is already installed and running. Without that service, the app has no privileged channel and the install buttons have nothing to talk to.
How the Shizuku Binder path actually works
The README includes a Mermaid diagram that traces a single operation. A user action reaches the Shizuku service, which communicates over Binder IPC with the system server, which in turn calls the package manager to install, uninstall or update. The app never holds the privilege itself. It asks Shizuku to perform the operation, and Shizuku relays it to the system.
The technical stack listed in the README is Kotlin for the language, Jetpack Compose with Material Design 3 for the UI, Retrofit 2 and OkHttp alongside Java HttpURLConnection for networking, and SharedPreferences for local caching. Concurrency uses native Kotlin threads plus a DownloadForegroundService. The README states that downloads and installations run on a standalone foreground service, so switching screens or minimizing the app does not stop them.
The backend is described as Google Apps Script with the Google Sheets API, used for what the README calls smart package mapping. The README also claims a zero-quota architecture: browsing and downloading are supposed to avoid GitHub API rate limits because the cloud engine handles the mapping. That claim is worth reading carefully. The app still downloads APKs from somewhere, and the README does not spell out the exact request path or what happens when the Apps Script endpoint is unavailable.
Installing ShizuCoreFetch and running a first operation
There is no build-from-source guide in the README. Installation starts from a prebuilt APK. The README's installation section gives five steps: download the latest APK from the Releases page, install it on your Android device, open Shizuku and start the service through root or wireless ADB, launch ShizuCoreFetch and grant the Shizuku permission, then browse and manage packages.
The README does not reproduce Shizuku's own start commands. It only states that root or wireless ADB are the two ways to start the service, and the Shizuku documentation is the authority on the exact commands. What the repository does give is the release download path for the app itself, which is the first step of the guide:
https://github.com/elhizazi1/ShizuCoreFetch/releases/latestOpening that URL takes you to the latest release, where the APK asset is attached. After the download, the install is a normal Android sideload: tap the APK, confirm the install, then open ShizuCoreFetch and grant it the Shizuku permission. The README does not document what the permission prompt looks like or how to revoke the grant afterward.
Once the grant is in place, the flow is: pick a package, trigger the install or update, and the foreground service carries the work through the Binder path shown in the architecture diagram.
The store metadata format and what it expects from developers
ShizuCoreFetch does not only consume packages; it invites developers to describe them. The README asks developers to add a shizu_store.json file to the root of their repository so the store engine can display tailored information, localized descriptions and custom developer details. The repository listing confirms that ShizuCoreFetch itself ships a shizu_store.json at its top level, so the format is used in practice by the project's own listing.
The README says the full documentation for structuring the JSON file is at the bottom of the page, but the cleaned README does not include that section. Anyone relying on the schema should read the live README rather than assume field names. This is a real gap: the project documents that the file exists and what it improves, but the excerpt available here does not show the keys.
The smart app matching feature is tied to this metadata. The README says a deep device scanner maps apps directly from the repo tree without extra API calls, and that action buttons are always accurate as a result. That is a design choice with a cost: correctness depends on the repository tree and the metadata matching what is actually installed on the device.
Limitations and cases where ShizuCoreFetch is the wrong tool
The largest constraint is the dependency on Shizuku. If Shizuku stops running, for example after a reboot when the service has not been restarted, the privileged path is gone and installs cannot proceed silently. The README does not describe what the app does in that state, whether it falls back to a standard package installer prompt or simply fails. That is a gap a prospective user should test before relying on it.
The second constraint is the backend. Package mapping runs through Google Apps Script and Google Sheets, according to the README's stack list. That is an unusual choice for a package index, and it means the browsing experience depends on a hosted script the project controls. The README does not document an offline mode or a fallback index. The zero-quota claim is about GitHub API limits; it says nothing about the availability of the Apps Script endpoint.
The third constraint is scope. The README lists silent install, uninstall and update, support for root, wireless debugging and test-only packages, plus local storage for downloaded APKs. It does not claim to manage system app permissions, freeze apps, or back up app data. If your problem is permission auditing rather than package installation, this is not the tool. And if you want an app store with signed, reviewed builds, a curated repository of APKs maintained by one project is a different trust model from a platform store, regardless of how the installs are performed.
How ShizuCoreFetch differs from a plain package installer
The obvious alternative is the standard Android package installer plus manual APK downloads. The difference is not the end result, which is an installed package, but the number of confirmations. The stock installer asks the user to confirm each install and each update. ShizuCoreFetch routes the same operation through Shizuku so the confirmation step is handled by the privileged service instead. For a handful of apps, the stock installer is simpler and has no extra dependency. For repeated updates across many packages, the Shizuku path saves the taps.
Another comparison point is Shizuku itself. Shizuku is the service that grants the privilege; ShizuCoreFetch is a client that uses it. Users who already run Shizuku for other purposes can evaluate ShizuCoreFetch purely as a front end: does its repository cover the packages you want, and is its metadata accurate? The README's own framing supports that reading, since it positions the app as a hub with a store engine rather than as a replacement for Shizuku.
The third path is root-based package managers. The README states ShizuCoreFetch supports root as one way to start Shizuku, so root users are not excluded. The distinction is that the app does not require root to function; it requires a running Shizuku service, which root is one way to obtain.
Licence, maintenance and upgrade cost
ShizuCoreFetch is licensed under GPL-3.0, and the repository includes a LICENSE file at the top level. For anyone embedding the code in another application, the copyleft terms of GPL-3.0 apply to distributed derivatives. That is a constraint to weigh before reusing the source in a closed product. This is not legal advice; read the licence text and consult a lawyer if the distinction matters to you.
The repository is not archived, and the last push was on 2026-09-15. The release history shows 2.4.0 on 2026-09-03, 2.3.0 on 2026-08-29 and 2.2.0 on 2026-08-27, so releases have been frequent in that window. Frequent releases also mean upgrade cost: as an Android app distributed as an APK, each release is a new install rather than a silent background update from a store. The README does not document an in-app updater for ShizuCoreFetch itself.
There is also a hidden cost in the metadata contract. If you are a developer listing an app in the store, you maintain a shizu_store.json file in your repository. When the schema changes, your listing is only as current as that file. The README does not publish a schema version, so there is no way to tell from the documentation alone when a listing needs updating.
Editorial conclusion
ShizuCoreFetch suits Android users who already run Shizuku and want a single place to install and update APKs without granting root. It is the wrong tool for anyone unwilling to run the Shizuku service, or for devices where Shizuku cannot be started. Before adopting it, verify that the release APK installs on your Android version, that Shizuku grants the permission the app requests, and that the app's repository mapping matches the packages you actually need.
Frequently asked questions
Is Shizuku a safe app?
The README does not evaluate Shizuku's safety directly. It states that ShizuCoreFetch runs without root and uses the Shizuku Binder API to execute privileged commands, which it describes as compliant with modern Android security policies. The safety of Shizuku itself is outside what this repository documents.
Does Shizuku root your device?
The README says ShizuCoreFetch runs without root and that root is only one way to start the Shizuku service, alongside wireless debugging. So the app does not require root, and the README does not describe Shizuku as rooting the device.
What can Shizuku be used for?
In this project, Shizuku is the channel through which ShizuCoreFetch sends install, uninstall and update commands to the Android package manager via Binder IPC. The README also notes support for root, wireless debugging and test-only packages.
Which apps use Shizuku?
ShizuCoreFetch is one such app: the README describes it as a Shizuku-powered application hub that performs silent installs, uninstalls and updates. The README does not provide a list of other Shizuku clients.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/elhizazi1-shizucorefetch)