Open theScrabi opened 8 years ago
+1, please let them package if it works!
Please release Superuser on F-Droid.
We could try to review this version of superuser on fdroid issue tracker: https://gitlab.com/fdroid/fdroidclient/issues
I also second this idea. Integrating the updated SuperUser with F-Droid certainly will bring more people to this project (both users and developers).
I submit that issue: https://gitlab.com/fdroid/fdroiddata/issues/303
Adding it seems fine. Only one issue though, with the gradle build - you're importing Widgets
, but the source code is not checked into the repo.
Also, there are clashes with the application id - in build.gradle it's one, and in the java files it's another. Please fix it, preferably to be different from the original from koush.
Let me know when all those issues are fixed and when a new release is tagged.
You want a git submodule?
Either git submodules or vendoring work.
Grmbl, of course changing package in AndroidManifest.xml breaks everything... Though I changed apk package name to me.phh.superuser instead of com.thirdparty
I don't want to urge you, but how is the progress? I'm really locking forward to see your (version of the) app on fdroid :)
The status is "let's break everything to handle Android 6"
That sounds sens full all right than :) good luck.
I understand your sarcasm but could you release something working before breaking everything?
If you are referring to me, i didn't want to be sarcastic. I think its cool that someone cares about this app, and i see that 6.0 is a important topic. Therefore good luck :))
Nope, I'm reffering @phhusson, I think having something working is good before breaking things out... BTW another branch is a good place for breaking. Just IMHO.
Oh, I didn't understand you were proposing yourself for maintaining that branch. I have no problem with reviewing/merging your PRs on a stable branch. List the available tags, you'll find what you wish for. Le 26 oct. 2015 19:23, "ildar" notifications@github.com a écrit :
Nope, I'm reffering @phhusson, I think having something working is good before breaking things out... BTW another branch is a good place for breaking. Just IMHO.
— Reply to this email directly or view it on GitHub https://github.com/phhusson/Superuser/issues/3#issuecomment-151236792.
Eh, Pierre, I didn't mean exactly that but thanks for being so open. Anyway,
Nothing prevents it obviously. And yes, it is now (as of drop_placeholder tag) fully NDK-buildable
I created a stableL branch based off drop_placeholder tag
wow! That's so cool! Last thing: a tag is required for F-Droid builds. Could you please make one? Thanks in advance! I hope that Loli-compartible SU coming!
Ok I pushed stableL-0.0.1 But I don't know what's the full current state. I know that placeholder/su executables and Superuser work, but I don't know about update.zip built by build-zip.sh Though I know for sure that the update.zip generated by the APK doesn't work (it is at least missing the placeholder file).
I can help whoever wants to give it some work, here are some informations: What's missing is in Superuser/src/com/koushikdutta/superuser/MainActivity.java and you can look at build-zip.sh to know what has be done. (Please first test build-zip.sh and the generated update.zip, I'm not 100% sure it works) I believe doRecoveryInstall is only missing the add of placeholder file. doSystemInstall is missing a lot of stuff, and I would advise to simply disable this method.
Hi @phhusson , F-Droid still rejects because of the application id, see https://f-droid.org/forums/topic/superuser-2/#post-17930
Can we do something about this?
I don't understand why F-Droid has problem with application id... And except for F-Droid, I have no reason to do that, and it requires a lot of refactoring. So it is really low on my priority list.
If we didn't have a policy about this, people could just fork other people's apps and there would be no control over who was upstream or who could update the app.
Unless upstream passed on the project to you, the same applies.
The package name is me.phh.superuser not com.koushikdutta.superuser, it's no theft.
Nobody said that on the forum post, so I just didn't notice. I also did not know you could change the package id of an app while keeping the old package names for all the java packages.
Oh ok, earlier in the bug you mentioned the clash between build.gradle and java files, so I interpreted as you had problem with it, not that it's a bug
Possibly, the signing part doesn't match your need. Feel free to request changes for it
Sounds to me like the line package="com.koushikdutta.superuser"
in AndroidManifest.xml
should go, though.
This line is used to determine the package of the R.java, and the package prefix of java classes for intents, this still means a lot of refactoring (a little less though than changing every package reference)
OK then.
Some more stuff I'm finding along the way:
These files should probably not be checked in, and you should have *.so.*
and *.a
in your gitignore:
Superuser/jni/libsepol/src/libsepol.a
Superuser/jni/libsepol/src/libsepol.so.1
In the Widgets
submodule, you checked in the support-v4 jar twice. Not really necessary, as it can be pulled via gradle.
I would also remove ant support (*.properties
, build.xml
, etc) since gradle on its own is enough. To make things simpler and easier for you.
Note that these are just suggestions, but they are not issues keeping me from building the app.
Thanks for that
would you be able to tell the use of Superuser.iml and Superuser-Superuser.iml?
They are IDE files, specifically for Android Studio. Ideally they should be removed too.
BTW, the build succeeded but the native binaries are not in the resulting apk. aapt reports no native code, and the apk weighs under 1M so they are definitely not there. I ran ndk-build
and gradle assembleRelease
.
The binaries are not meant to be in the APK, ATM
Then should I be running ndk-build
at all?
Reping @phhusson
Sorry for the long time to reply. So my current status on that is: This APK won't install the root itself, it will only be the UI of the root. So, no ndk-build at all, but to install the root, users will have to go through super-bootimg (either superuser.zip or from a GNU/Linux)
Wait, so is the actual su downloaded by the app, or downloaded manually by the user separately?
The "su" itself is unusable, it must be either put in /system or in initramfs, so yes the user has to install/download it separately.
The question might rise again if/when I provide an update method of the su binary through the app. I'll notify you when/if that happens
So if the app doesn't install nor update the su binary, what exactly does it do?
Also, if we should not be running ndk-build at all, remove that whole section from the README.
It is the UI of the su binary. When an app tries to gain root access, the SU app will show a popup, asking confirmation from the user to give root access to the requesting app
Then remove the whole native build section of the README.
The application and the su binary are in different sections of the README. A user can still want to build its own "su" binary to include it in his device.
Enabled in https://gitlab.com/fdroid/fdroiddata/commit/af2fb6393897e854c013e99612b1ebc8689c4224. Should appear within a day.
Awesome, thanks !
I've updated the app, can you rebuild it? Thanks
Is it possible to bring your version of superuser to fdroid? If so it would be nice, since fdroid version still does not support android 5.0 and higher.