Yet abother Linux for Android app

223 views
Skip to first unread message

Sergii Pylypenko

unread,
Apr 5, 2014, 3:53:45 AM4/5/14
to proo...@googlegroups.com
I've created an Android app, based on your most wonderful PRoot, that will install and launch Debian on non-rooted Android, pretty much the same as Corbin's GNURoot app, but with a graphical desktop environment.

https://play.google.com/store/apps/details?id=com.cuntubuntu

Compilation instructions: https://github.com/pelya/commandergenius/tree/sdl_android/project/jni/application/xserver-debian

It also includes a proper X server, so the screen redraw speed is manageable, and it supports mouse natively.

There's only one installation image available - Debian Wheezy with XFCE desktop, and it's not split into internal storage / SD card parts, because modern Android devices have virtual SD card partition, which is using space from internal storage anyway. Also, no x86 support, I'm planning to add it in the future.

Corbin is also planning to integrate that X server port into his GNURoot, so you'll even have some choice of distributions in the future.

Cédric VINCENT

unread,
Apr 5, 2014, 12:24:00 PM4/5/14
to proo...@googlegroups.com, Sergii Pylypenko, Corbin Champion, heeh...@gmail.com
Hello Sergii,

I'm glad to read a new awesome Android application uses PRoot! I
don't [want to] own a Android device but I'll spread the word around
me about your project, for sure!


> it's not split into internal storage / SD card parts, because modern
> Android devices have virtual SD card partition, which is using space
> from internal storage anyway.

Does this mean the "link2symlink" PRoot extension is not useful
anymore? (CCed Corbin and hhm about this)


> Corbin is also planning to integrate that X server port into his
> GNURoot, so you'll even have some choice of distributions in the
> future.

Happy to know there is some kind of cross pollination between these
two great Android projects!


Thanks for the notification and for your grateful words in the "What's
New" section of your application ;)

Cédric.

Sergii Pylypenko

unread,
Apr 6, 2014, 8:04:21 AM4/6/14
to proo...@googlegroups.com
I'm not using link2symlink - it's easier for me to just use internal storage and do not bother with SD card, because I'm targeting newer devices, like Galaxy Note, but there are many older (but capable) Android devices with small internal storage partition, which will need that extension, so I hope GNURoot will support it.

Corbin Champion

unread,
Apr 8, 2014, 1:27:09 AM4/8/14
to proo...@googlegroups.com
Yes, I am excited too.  Sergii has done great work!  I look forward to collaboration that will make both of our apps better.

I think a couple of PRoot extensions are getting confused.  link2symlink is still necessary.  Android doesn't permit non-root users to make hard links.  This causes many issues on non-rooted devices, like apt-get will not work properly.   

The one that would not be necessary for Sergii's target users is the mmap-noexec, which attempts to allow executables to run off of the sdcard.  I am still very much interested in that, but haven't yet dedicated time into 1) debugging why it failed on Android, but not on a pc with a similar mounting, 2a) fixing it or 2b) trying out other alternatives.

You guys are great!

Thanks,
Corbin

Cédric VINCENT

unread,
Apr 12, 2014, 4:31:20 AM4/12/14
to proo...@googlegroups.com
Hello all,

> I think a couple of PRoot extensions are getting confused.
> link2symlink is still necessary. Android doesn't permit non-root
> users to make hard links. This causes many issues on non-rooted
> devices, like apt-get will not work properly.

My mistake, I thought "link2symlink" was also used to create "fake"
hardlinks between the internal memory storage and the external one (SD
card).

> The one that would not be necessary for Sergii's target users is the
> mmap-noexec, which attempts to allow executables to run off of the
> sdcard. I am still very much interested in that, but haven't yet
> dedicated time into 1) debugging why it failed on Android, but not
> on a pc with a similar mounting, 2a) fixing it or 2b) trying out
> other alternatives.

Hum, I'll try to investigate why mmap-noexec does not work on ARM next
week (using QEMU system mode).

Cheers,
Cédric.

Cédric VINCENT

unread,
Apr 22, 2014, 4:39:08 AM4/22/14
to proo...@googlegroups.com
Hello all,

On Sat, Apr 12, 2014 at 10:31 AM, Cédric VINCENT
<cedric....@gmail.com> wrote:
> Hum, I'll try to investigate why mmap-noexec does not work on ARM next
> week (using QEMU system mode).

mmap-noexec is really naive (it was just a PoC), that's why it doesn't
work on ARM. As of my understanding it works on x86_64 because
PROT_EXEC != PROT_READ on this architecture, however there are some
scenarios where mmap-noexec might fail. As a conclusion, it requires
more work to make it reliable.

Cédric.

Corbin Champion

unread,
Apr 23, 2014, 1:48:56 AM4/23/14
to proo...@googlegroups.com
Thanks for the feedback.  I plan on spending time soon looking into using the sdcard for storage of most of a rootfs.  It remains a strongly desired feature.  Now that so many other things are working, the next sprint of time I can dedicate toward writing extensions for proot will be focused on this (I will also spend time testing the example you are creating that shows how to run a native android binary without proot attaching to it).  

Can you outline what the future work is that you think would be necessary to make this more robust and properly test it? Just whatever you already have in mind, I can start from there.  

Also, I had an alternate idea that should work, but would also have a performance penalty.  What if when an executable was going to be exec'd or mapped, it was copied off of the noexec partition first.  Then it could either A) be deleted, or B) be deleted only when more space is needed.  B) requires checking whether the file has changed since last being touched but B) has less of a performance penalty as a user only uses a small fraction of the executables at a time and probably only uses a small portion of a linux distro over and over in their normal use. This would only be desirable if the noexec extension cannot be made to work or if this had a noticeably smaller performance penalty.  

Another alternative would be to intercept a lot of system calls and make sure any file that might need to run is stored on the internal storage and anything else is stored on the sdcard.  That would get more than half of a rootfs on the sdcard and would have a very small performance penalty.  The negative here is this would be a more complicated extension with more test cases to try.

Thanks,
Corbin
Reply all
Reply to author
Forward
0 new messages