Your Superuser for f-droid about superuser HOT 60 OPEN

+1, please let them package if it works!

from superuser.

Please release Superuser on F-Droid.

from superuser.

We could try to review this version of superuser on fdroid issue tracker: https://gitlab.com/fdroid/fdroidclient/issues

from superuser.

I also second this idea. Integrating the updated SuperUser with F-Droid certainly will bring more people to this project (both users and developers).

from superuser.

I submit that issue: https://gitlab.com/fdroid/fdroiddata/issues/303

from superuser.

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.

from superuser.

You want a git submodule?

from superuser.

Either git submodules or vendoring work.

from superuser.

Grmbl, of course changing package in AndroidManifest.xml breaks everything...
Though I changed apk package name to me.phh.superuser instead of com.thirdparty

from superuser.

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 :)

from superuser.

The status is "let's break everything to handle Android 6"

from superuser.

That sounds sens full all right than :) good luck.

from superuser.

from superuser.

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 :))

from superuser.

from superuser.

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" [email protected] 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
#3 (comment).

from superuser.

from superuser.

Nothing prevents it obviously. And yes, it is now (as of drop_placeholder tag) fully NDK-buildable

from superuser.

I created a stableL branch based off drop_placeholder tag

from superuser.

from superuser.

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.

from superuser.

from superuser.

Can we do something about this?

from superuser.

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.

from superuser.

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.

from superuser.

The package name is me.phh.superuser not com.koushikdutta.superuser, it's no theft.

from superuser.

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.

from superuser.

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

from superuser.

Possibly, the signing part doesn't match your need. Feel free to request changes for it

from superuser.

Sounds to me like the line package="com.koushikdutta.superuser" in AndroidManifest.xml should go, though.

from superuser.

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)

from superuser.

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.

from superuser.

Note that these are just suggestions, but they are not issues keeping me from building the app.

from superuser.

Thanks for that

from superuser.

would you be able to tell the use of Superuser.iml and Superuser-Superuser.iml?

from superuser.

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.

from superuser.

The binaries are not meant to be in the APK, ATM

from superuser.

Then should I be running ndk-build at all?

from superuser.

Reping @phhusson

from superuser.

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)

from superuser.

Wait, so is the actual su downloaded by the app, or downloaded manually by the user separately?

from superuser.

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

from superuser.

So if the app doesn't install nor update the su binary, what exactly does it do?

from superuser.

Also, if we should not be running ndk-build at all, remove that whole section from the README.

from superuser.

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

from superuser.

Then remove the whole native build section of the README.

from superuser.

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.

from superuser.

Enabled in https://gitlab.com/fdroid/fdroiddata/commit/af2fb6393897e854c013e99612b1ebc8689c4224. Should appear within a day.

from superuser.

Awesome, thanks !

from superuser.

I've updated the app, can you rebuild it? Thanks

from superuser.

No, you have not. There is no new tag.

Also, we check for updates daily, so no need to ping any thread.

from superuser.

I already looked a while ago, and I couldn't find it.
Now that you say it exists, I've checked again. It takes some time to find, but now I have some documentation, but it doesn't seem to match what you say:
In the commit you pushed for this app, "Auto Update Mode' is to None, this means it doesn't update, no?

from superuser.

Auto Update Mode is for the app to be updated automatically, i.e. for new builds to be generated automatically. Update Check Mode is what checks for new versions.

Neither will work if you don't bump the version and push a new tag.

from superuser.

@mvdan for my own curiosities, and only since I'm subscribed to this ticket, what happens in the state where Auto Update Mode is off, but Update Check Mode is on? What happens if the reverse is true?

from superuser.

@mvdan I've pushed 1.0.3.3 tag, with 1.0.3.3 manifest, but it's still 1.0.3.0.
I'm seeing on https://f-droid.org/wiki/page/me.phh.superuser that the bot did found the updated app is now 1.0.3.3, but it still has only built 1.0.3.0

from superuser.

That's because auto updates are not enabled. And if they were, the build would have failed - your tag naming is erratic.

from superuser.

Please link to a proper documentation.
I'm getting tired (and probably you too) of this.
Le 19 janv. 2016 12:24, "Daniel Martí" [email protected] a écrit :

That's because auto updates are not enabled. And if they were, the build
would have failed - your tag naming is erratic.

—
Reply to this email directly or view it on GitHub
#3 (comment).

from superuser.

https://f-droid.org/manual/

from superuser.

After reading at least 6 times the documentation over several days, I can say that this is not a proper documentation.
Nowhere in the "Update Check Mode" one can understand this field doesn't concern build.
(Unless perhaps you expect an app developper to read the full doc, including totally related infos concerning how to setup a fdroid repo)

As for the choice of branch, I still have noone who wants to support stableL branch, but many users who want to have current branch of SuperUser available on F-Droid, so I'll make the switch.

I'll send you patches to fdroiddata, so I know what is happening.

from superuser.

Updated to the new version: https://gitlab.com/fdroid/fdroiddata/commit/2dc411

from superuser.