Repository navigation
Replies: 20 comments
|
Thanks for pointing that out! 🙂 The original meaning in Chinese is actually that the two versions share the same package name, version code, and signature, so they can replace each other when installing (overwrite installation). English Version of readme is translated by a contributor, thus causing confusion. |
|
No problem and you are welcome. The way you put it looks way better, feel free to let me know if/when it gets fixed by you or anyone else and thank you in advance. In the meantime I've noticed another thing (the first point from the quoted text below) and just decided to ask Copilot (GPT-5) to check for other typos/inconsistencies and here's the output (most can be ignored I guess, except maybe the first part, you can decide if it's worth making any changes based on this, I'm just pointing them out just in case):
BTW - I really hope that you can reconsider making it work/install packages without an authorizer (Root/Shizuku/Dhizuku, etc.) and ofc. with limited advanced install options, because they obv. can't be passed through without elevated permissions like with the 3 above, because only a few installers don't work without any of them, but most like SAI (by Aefyr - the most popular session installer that doesn't require elevated perms. by default) do work on most systems and there's at least a year until Google makes the installation harder with the controversial changes that were made public recently and those won't affect everyone (those with custom roms {not necessarily rooted}, without GApps or with ones, but not being kept up to date and/or with older OS vers.), so we have time, besides - the limitations/restrictions as far as I understand won't affect manually installing untouched packages that are on and from Play Store or those which package names (and signatures) are being "registered" in the PS's Dev. Console in future. I guess if you want to bother with this, you can look at and maybe even reuse code from SAI, Inure, AppManager, etc. - all of them don't necessarily need additional setup/authorizers/elevated permissions and are open sourced, there are others I know about and use/d, but they are closed-source (being app or file managers and modification tools with integrated session installers). Personal reference: https://github.com/wxxsfxyzm/InstallerX-Revived |
|
Very, very quick testing in an online A.16 emulator/VM (haven't even tested with bundles/splits) and I wish there was an option to keep the min/targetSdkVersions info always expanded by default to show the corresponding/resolved OS numbers, just like the option for expanded ver./build numbers, instead of me having to tap to expand them to 2 lines. The installer source package name (like com.android.vending) field to be also changeable straight from installation dialog's advanced/extended menu options, being as an input field, instead of suggesting to change it from the app's UI, not that spoofing this nowadays makes much sense or difference... I found that I like more the additional (MiUi) amoled black theme, rather than the default one, at least on AOSP/Pixel Experience. |
What is the point forwarding the install request to System Package Installer？If you really want to do this, you can directly open apk file(s) with stock installer then.
Many has reported this request to me, but there are some technical issues impacting performance when implementing this, eventually, it will be added, please wait😊
IMHO there won't be much install sources on your phone, simply add them to settings, and you can choose between them conveniently. Also, making that card editable will make it looks ugly, and such a small card can't display many characters, making selections is faster, what do you think? |
Sure, but for standalone .APK only, but since so many apps nowadays are distributed as bundles (being separate .apk files of the same package with DPIs, Lnags., Arch., assets, etc. or in an .apks, xapk, .apkm, .etc. archives) - this is not a viable option anymore, since the sys. P.I. doesn't support bundles and is very basic non-session installer, but even if it did support those, it still won't let you pick which splits to install from a bundle archive, or print/show an error msg. when the installation of any package fails for some reason (it happens), unless there's something IDK...
You mean by creating diff./separate profiles and including each spoof source P.N. I might want to each of them ? (I haven't tested this or if I can use multiple separated by a comma/space/in a new line or something else in the same input field of the default profile - sorry), anyway, I think that it won't/shouldn't be a problem and there might be enough space, or if it uses the so-called full screen keyboard, so when tapping, it will show a huge full-screen input field, letting you type as many characters as you want, it won't be beautiful, but the idea is to be able to Paste the P.N. on the go, not having to cancel the installation and go to the app to edit it and then install again. You are right tho - there usually aren't much install sources, except when I'm testing things and forget to go to a profile to add a particular package name that I intend to spoof as a source before trying to install an app, then I remember and cancel + setup or have to install again after the setup with the P.N. I intended to install & spoof with in the first place, which I don't necessarily have to have already set-up as is just temporary while the tests last. |
|
Based on testing, SAI does not work on some devices. Nowadays, many custom Android OS versions enforce very strict controls over app installation. Without privileged permissions, I also cannot install split APKs through SAI. In many cases, modifications to the system’s Package Installer break this functionality. Even if I were to find a way to support non-privileged installations, I would quickly be overwhelmed by 'Why doesn’t it work?' questions from the Chinese community. Keep in mind that the only reason you can install bundles without privileges is because your system’s Package Installer happens to support it — not every system does. Providing full compatibility across so many different systems, each with its own Package Installer modifications, would require starting from scratch and is extremely difficult to maintain.
This requires the app opening a single privileged session and manipulate installation process inside the pm api, with system package installer, it will send requests to system package installer one by one. I can't say whether it could work for all systems without errors, the event happens outside our app is beyond control, many exceptions may occur.
You can use this, This list takes effect globally. Once you set it here, you can temporarily select it for a single installation using any profile.
|
|
I might not win the argument here, but just because some installers don't work on some configurations doesn't mean that they won't on others, like if not anything else, then AOSP/Pixel, sure SAI and forks/mods might not work everywhere and even disconnect the A.16 online AVD I tested with, but the APKMirror installer and others that don't explicitly require authorizers do work, but even if they still don't on Chinese brand device, that doesn't mean that there shouldn't be the option for the rest of us. Anyway, you can at least remove the useless non-selectable greyed-out Authorizer's IDK what/where is the menu on your screenshot and how to reach it, because it's not in English. What does the profile's Scope button do ?, no explanation for it at all in the app or especially the ENg ReadMe (I'm eagerly waiting for the typo fixed readme btw). Please start using English for every release's changelog, so those that know ENg can understand what's actually changed, without having to waste time with the individual commits, which are cluttered with translations, spread across diff. branches and it's hard to follow the ones that really matter. Also, the browsers that support page translation (mine - Cromite on android - doesn't), conveniently ignore the texts in Thanks for the detailed explanations btw. As I understand, you use code from InstallWithOptions, I hope the sharing goes both ways (<>) and that you will eventually contribute to IWO with things you find and code/options you implement in InstallerX Revived that aren't yet in IWO ;) BTW I tested your IXR on A.8.1 x86 Live Boot and not only it can't install anything, being with Shizuku or Root (which is already reported and I'm waiting for the fix in October), but also: The Save button is kind of unnecessary, either a change has to be applied immediately or at least the button to be hidden when no change has been made. |
I believe this app is quite simple and doesn't have many pages, what I send you is just a guide for you to find this - which is not hard to find.
Select apps to use the exact profile. Meanwhile Profile 'Default' does not need to be modified as apps not selected will use default.
Please understand I'm Chinese, I have no duty to use English everywhere, and if you could go to see the commit history, you could find that the docs is maintained by another contributor, not me. I have informed him as soon as you send me the post, what you should do is either wait patiently for him to decide or send pull request to me.
With all due respect, I must refuse. The original purpose of developing this app was to replace the system installer in Chinese-customized Android systems. Not only is the main user base Chinese-speaking, but nearly everyone who has collaborated with me on the development also speaks Chinese. On the platforms I use, I directly reference GitHub’s release page as the changelog. If it were written in English, it would cause a lot of inconvenience. Therefore, publishing the changelog in Chinese is intended to better accommodate the majority of users.
If you could go to IWO's issue, search for me, you can see I have told him what I found he might need - I'm disappointed that you didn't even do a research first.
I myself only maintain SDK 34 - 36, which is declared clearly in ** EN README ** file. So why don't you report issue to my repo(already one, I guess you didn't check issue either) so that other contributors can solve your problem?
Not planned.
It won't be a good idea to remove the save button, we have tested thoroughly in previous alpha. If you have better solutions, pr welcome. |
|
Regarding the menu in the screenshot - thing is that I've only used it on non real tablet devices in landscape, so the layout is different from your screenshot, call me stupid if you want, but there is basically only 1 possible menu that it can be and it doesn't look the same for me and I don't only mean because of Chinese vs English, for me there are buttons there that I don't see on your SS, it's highly possible that they are below for you and you did cropped it, in any case I'll have to do more testing when I have more time, because I haven't had much to fully test it extensively, only for a few minutes and I even mentioned it in my previous comments here. Thanks for the Scope explanation. Btw the button for me is with a label, but I noticed that it doesn't show a tooltip hint when it's not labeled like when in portrait, or at least it didn't show for me and I know how is called, only because I usually see the label, but not on every configuration with various DPIs and the UI layout seems screen orientation dependant and doesn't look the exact same everywhere. Regarding the English in releases changelogs - it makes little to no sense to use english for the alpha and not for the stable releases, when you can do what you already do for the alphas, but for the stable as well, using a divider (above/first Chinese, below/second - English for whoever needs it, which can probably be under collapsed details), they do include EN here for example: https://github.com/zhongyang219/TrafficMonitor/releases, so I don't see why you can't as well, besides it's not that crazy of a thought, given that you already do it, but selectively and the default readme is in EN anyway, so you can at least be consistent. This is my reasoning for suggesting it, others do too, so I'm not the only one. You seem to want to please the majority of current user base, which according to you is Chinese speaking, but using English like in code/commits and readme will not hurt, but quite the opposite - increase the global user base. There are more and more increasing volume of issue tickets written in English, so your user base might not be primarily Chinese as you think, at least not lately. Some users just skip and don't bother to deal/get involved with repos that don't use En as primary, I can tell you that for sure. As a matter of fact I manually check your repo every single day as a guest from a browser (couple of others as well), along with every single commit's title in the main branch and issue tickets in English, plus release notes when there's a new one, even tho I don't understand the points and having to translate them (stables), which is partial as I already explained and since I started monitoring your repo a couple days ago, the only one making changes by pushing commits is non other than you and I haven't seen anyone else editing the EN ReadMe, I don't claim that there isn't, as the commits history clearly shows that there are other contributors, I'm just saying that I saw only you making changes since I monitor it, so excuse me, but your assumptions are kind of/little bit baseless that I didn't do my research/homework, basically calling me lazy. You created only 2 issue tickets in the IWO repo, in which at the time of me creating this discussion, you only asked for help/advice from Zacharee, which he provided both times and you gave like just 1 proposal/suggestion, which is for Zacharee to use Minify, I couldn't find anything else there by you, being PRs/commits or whatever else and I'm ofc. and obv. not counting the recent proposal by you in one of my tickets there, about the caching during staging, which was around the same time you responded here (a few hours ago), so no need to be disappointed.
Clearly the minSdkVersion drop haven't been actually tested in reality in an emulator/VM or a real device. How can I know and mention about the existing issue, if I haven't checked them !?, baseless assumption and a false claim, besides - I don't see a point in me basically commenting something like "me too" in the ticket there, especially when the contributor to blame for the untested code already commented that it will be taken care of in October, nothing else I can do or contribute with in there that will speed this up. I tested it on A.8.1 emulator by the same time it was reported, or perhaps I should've created a duplicate... "Not planned." => That's really, really unfortunate. I hope that you will change your mind eventually. BTW, Zacharee just added a theme selection based on my suggestion. I shared my suggestion about the Save button, sorry, but agree to disagree, nothing else I can do. I get that PRs are welcome, but I'm not a coder, the only languages I know are 2 human ones, no Java/Kotlin, etc. coding ones and I'm not a Vibe Coder, so I don't want to submit an AI generated slop. |
|
Thank you for your detailed feedback and for taking the time to share your perspective. I'd like to clarify a few points about the project's direction and my approach as a maintainer.
Thank you again for your interest in the project. I hope this explains my position clearly. |
|
Highlights in /Releases aren't translated (don't have a button to expand ENg text) - that's on purpose I guess...? Thanks for listening and translating most of the other changelogs text btw. Can the installation notification channel be with lower priority by default set in code, instead of making a sound, especially when the app is configured to show a dialog (which is the default option) ? If an app installation fails for some reason and it's not an update & not being installed already, the magic wand icon button next to the app label in the install dialog when pressed shouldn't try to launch the app or the App Info system settings and ofc./obv. fail, it should either not do anything or continue to expand the dialog details info availability buttons (like SDKs), just like before proceeding to install or not be there at all in such cases. The preferred installer source (from your screenshot way above) and the 3/4 other items below aren't available in the MiUiX theme style's layout, only in the default one, that's why I had a hard time finding it as I use the MiUiX one, so please sync the themes and availability of options between them as soon as possible. Would be nice if they were editable, instead of having to Delete and reAdd an item with P.N. & label. Shouldn't both the SDK info options be located under the installer options, instead of scattered around, like the new one in development to always show on 2 lines being under the installer options, but the one to show the info is in the profiles and I wonder why, because one would either like to see this info or not at all, I doubt anyone would want to configure and show/display it per profile, but hey, maybe I'm wrong about that part, still it would probably make more sense if they are on one place, even tho having more flexibility won't hurt. I would like to have options like the Disable Verification one and some others always enabled by default, but unfortunately only the ones that have toggles in the installer settings or profiles are persistent, and many don't have switches there, so they don't stick and aren't enabled for the next installation. Please if you can Make the splits selection menu with categories and with select all checkbox per each category (Arch., DPIs, Lang., etc., additional assets should fall under Others at the bottom) and sort them by a type, instead of the current unsorted mess. In an x86_64 emulator the non-native arm64-v8a split is being automatically selected by default when there's an x86_64 split available already, which might use a translation layer (bridge) or whatever, the app be slower and even cause errors in logcat like e_machine: 40 (EM_ARM) with some badly coded apps (I've seen it many times with apps on A.8.1 x86 when I attempt to run them {not being installed with InstallerX}). The language splits are being translated to the system language, instead of the IXR's language, which is in English in my case, because the system lang. isn't supported, but if it was, I would still want to see it in English, sure, the IXR's lang. can be changes now from the App Info on A.13+, but the problem is that there's isn't in-app language selector on lower OS versions (8 to 12), so I'm forced seeing the lang. splits in the sys. lang. and can't force IXR to use English, like I can on A.13+ to avoid this mess. The Bypass Low Target SDK Block option in the settings is shown on A.13 as well, but it's only an A.14 and up thing and it should be hidden for systems with SDK/API 33 and below. There are other options that should be hidden as well and maybe even ones that should be shown instead (not so sure about that last part)... |
Yes it is. Like I said before, I use this Release Note elsewhere, so this is the best I can do.
You can set it yourself in system settings.
I will never support this, as some of the dependencies require SDK 26
This is already part of plans, please wait patiently.
They are not the same.
This is not releated to my app, this is a hidden system setting, the switch is it's current state
If you have a high-efficient method not affecting loading speed, pr welcome.
x86_64 is x86 (64bit), there is nothing wrong.
Let me clarify again I will never support such low SDK, and you SHOULD NOT report it to me. If you really think it is problematic, the available things you should do is either create an issue and wait for someone to fix it for you or fix it yourself and send pr to me.
I have said it isn't completed, it's in progress, but here you are, complaining about it, what a shame.
Not planned.
This will be fixed.
bug confirmed, will do a fix |
I know !, I meant to be silent by default, because it doesn't need to make a sound on every install at all, maybe you aren't paying enough attention of what was actually written...
I'm sure there is a way/workaround, but at least there are alternatives for A.5-7 (if not with Shizuku, at least manually with ADB or Root), so whatever.
Since I can't read minds and know what's planned and what isn't (nor there's a public list of ToDo's on GH), I had to mention it, I hope you understand. I'll wait, NP ;)
They kind of are, as they both control the display of the same exact thing, one is to show it, the other is to show more of it.
Maybe you misunderstood what I meant (or I did of what you meant)..., because how can it not be related to your app, when it's in the Extended Menu when installing packages ? and it's an inherited option, used to bypass the Play Protect check as far as I understand it, and it's not a switch, but a CheckBox, with a description of "Disables package verification during install. This is not signature verification." and it's persistent in IWO among installs, but in IXR it's a one time thing per install and it has to be enabled every time (there are others that don't stay enabled as well as I mentioned).
IDK, check what other apps like SAI are using and add a master mark all of each category. If I could code it, it would've been implemented already.
Technically, but not exactly (x86 = 32-bit, x86_64 = 64-bit) and I already pointed out what's wrong, which is celarly and obv. mislabeling an arm64-v8a package as x86 and not as x86_64, which is in many cases the exact name of the split .apk file, in the brackets it correctly indicated as 64-bit, IDK how can you claim that there's nothing wrong there, might be a little typo, but it's definitely not ok.
What SDKs are you talking about, this is about the Dark/Light mode, which can't be set from the app nor from the system on some configurations of which the app already runs on, so you are supporting them already, the same goes for the missing language preference in the app (your quote is not exact, bit a stich and vague, so I guess this is what you replied to). Also who says I'm reporting everything to you ?, I've also made some personal points/notes to keep track of things, you have the benefit to read them and act on them if you want, there are no obligations whatsoever. Your app's minSdkVersion is 26 = A.8.0 Oreo, where there's no system dark mode toggle, which your app needs / respects to go dark, nor there's a system language selector per app in the App Info settings. IDK how can other developers acknowledge this and most put preferences for both inside their apps settings, but you are stubborn and refuse.
I know it's not finished. Complaining !?, where did you read me complain, because it's certainly not here and I haven't wrote anywhere else anything about your app, you are confusing things my friend, as those are not complaints, not at all, but feedback, reports, ideas/suggestions based on things I noticed and some facts, I hope you finally start to make a difference between them.
OK. Nice (we found something you agree on).
This is not something I wrote, so IDK who are you quoting (a mess, please when you quote, do actually quote 1:1 copy>paste, else it's a random out of context text in a quote block and doesn't match what the other party wrote exactly, it's one thing to cut/crop it in order to shorten it, but it's another to stich text together like you did, with the other text between missing, essentially making the quoting pointless).
I'm not sure what's this about (the Bypass Low Target SDK Block perhaps...?), but OK, thanks anyway. |
How many times need I tell you I myself maintain SDK 34-36, lower is supported by the community and other contributors and this writes very clearly. It is you who is stubborn and refuse because I keep telling you the right thing is to write issue so other contributors could help you, but you just keep bothering me and try to persuade me to maintain all this mess. I'm afraid I need to tell you I hate that. |
|
That point I forgot (honestly). Sorry. |
Will be handled in the future builds
Sorry, I only meant to briefly refer to the part you mentioned regarding ABI selection. This is fixed just now, you will see it in next alpha build |
|
Disclaimer: Below are personal notes for/to myself to keep track of progress and what I've discovered while testing (whoever wants to read and fix) ! It now works on A.8.1.0 with Root & Shizuku, but: The following is not necessarily related to Oreo: Idea: When first launching iXR, being from it's shortcut icon or when selecting it as installer for a package, to prompt for an authorizer then, instead of having any pre-set as default (Shizuku is the default one set by the devs.), it should also ask to grant Root/Shizuku, etc. immediately after selecting each from the authorizer settings if not granted before, but it should not refuse to launch if none available or picked when it prompts, should be skippable, not mandatory, even if it won't be able to install anything that way. In https://github.com/wxxsfxyzm/InstallerX-Revived/blob/main/app/src/main/java/com/rosan/installer/build/Architecture.kt#L10 |
|
Unfortunately proper tests at least of the UI(s)/UX - side to side and in different orientations still aren't being done by anyone, or they would've seen and reported/fixed the following, weeks ago, or they don't care much, so I'm just typing this here to keep track of: With GM3/MD3 the Palette Style selection dialog not only isn't scrollable when it can't fit / be fully shown, has too much wasted space (unnecessary margin/padding between the diff. listed style items and it's too wide) and it gets cut-off in landscape on phones (probably in portrait on small screens too), but it also closes itself when rotating, the same behavior that can probably also be monitored on other such pop-up dialogs/prompts in the settings, the Theme Mode dialog is also unnecessarily wide. The landscape (aka. tablet/big screen) experience is also really unnecessary, bad, inconvenient and a huge space waste on phones, splitting the screen estate basically in half with the Miuix style, I wish it never existed, the 2 buttons for Profiles & Preferences to be on the bottom/top as tabs, or to at least be an option to disable it in any theme style and menu, no matter what. IDKW but months later and the installer is still set to Shizuku by default unfortunately for some reason if any, instead of none (not necessarily/explicitly the "None" option), instead of asking the user to select the one they have/want on launch, including when the installer is called, especially when Shizuku isn't active/running (which service also gets auto stopped and can't be activated without Wi-Fi AP/HotSpot & Wireless Debugging on A.11+, another device, USB cable and ADB, or root), a selector should show every time it can't detect the default Authorizer as activated, instead of throwing a message in the installation dialog, having to cancel, deal with the authorizer and try to install whatever again. IDEK why would an issue ticket like the |
|
When the preferences are open and I install something, I would like the full InstallerX's UI to not be hidden/excluded/dismissed from the recents, so I can easily switch/go back to it and where I was before the installation, I think activities and The usual dialog with extended package info details and menu button doesn't show for/when there are multiple (more than 1) standalone apk files in archives, like the 2 online & offline inside the action CI artifacts .zip file, you can just install and nothing else, there's no Next button to adjust install options, see permissions, etc. It would be nice if in future the installation dialog can also show/list the availability of libs (if any) in a given standalone package. In Profiles the In The 3 cards in the bottom of the The set/unset as default installer both show messages overlapped by the NavBar with GMD3.
Unfortunately InstallerX Revived seems to show as Open/Share handler for everything ( |
The official branding is I'm not even sure if a PR will be accepted/merged/appreciated if I make one, or it will be in vain (I hate to waste my time in vain, which might be the case here in this topic)... Edit: Ref.: apilevels.com |
Uh oh!
There was an error while loading. Please reload this page.
Hey @wxxsfxyzm, I've noticed a typo on line 138 of the English ReadMe, where it says:
Both versions share the same package name, version code, and signature, and can be installed side by side. Please download according to your needs.-> it should becan't.I really hope it's not a problem that I'm letting you know that way (I don't see why it should be...). ;)
All reactions