[Commotion-dev] Single su (aka Shell Fork)

Thu Aug 30 15:44:01 UTC 2012

I think your approach has a lot of potential for streamlining the
handling of root in Android apps.  I'm still trying to wrap my head
around it, so that's where a lot of my questions come from.  Then I'm a
bit dogmatic when it comes to "as simple as possible".

Will, could you reissue your patches without the API change and removal
of the wifi lock?  Or if the wifi lock is an issue, that should probably
be handled separately.  Also as a stylistic thing, I think there is no
need to leave in commented out code, since that code will always be in
the git history.  But others disagree on that one.

.hc

On 08/30/2012 11:27 AM, Will Hawkins wrote:
> Hey Hans,
> 
> Josh, Andrew and I discussed this further offline. We talked about
> making this change to interact with fork via stdio in a future release.
> 
> I talked about the rationale of using TCP/IP and session keys in the
> first place (debugging convenience, asynchronicity of issuing
> control/input commands) and the reason why it's not a big deal to switch
> over. That said, staying with TCP/IP at this point seems like a good
> idea to us so that we can have a fixed debugging target while fork is
> integrated with MeshTether. As far as I can tell, the change to this
> model of interaction between user and fork would not significantly
> change the API.
> 
> I am really glad that you provided this level of feedback. You and other
> Guardians (n8fr8) are very talented developers and I look forward to
> incorporating your bug reports and feedback.
> 
> Thoughts?
> 
> On 08/29/2012 05:38 PM, Hans-Christoph Steiner wrote:
>>
>>
>> Would it be possible to start 'fork' in a Java Thread, then interact
>> with it using stdin/stdout using StreamThread or something like that?  I
>> would be nice to not have to use TCP/IP and a session key.
>>
>> .hc
>>
>> On 08/28/2012 05:24 PM, Will Hawkins wrote:
>>> Hey Hans,
>>>
>>> Replies inline.
>>>
>>> On 08/28/2012 03:36 PM, Hans-Christoph Steiner wrote:
>>>>
>>>> Wow, it turned into quite a project.  It might take me a bit of time to
>>>> wrap my head around it. A couple of questions:
>>>>
>>>> - Is this for use in other projects besides MeshTether?
>>>
>>> Could be. :-)
>>
>>>> - does fork require android-16?  That will eliminate the majority of
>>>> deployed devices. This is set in 0001-Add-fork.patch
>>>
>>> Does not require it, as far as I know. I only put in 16 as the default
>>> because it's the SDK platform that I have installed on my machine. The
>>> gist of what's going on there is this:
>>>
>>> The MeshTether app wants to be notified using an Android Handler object.
>>> To include the ability for the fork Java API to include this
>>> functionality and build properly, it has to "link" against android.jar.
>>> (At least that's the way I understand it.) So, as a default I used what
>>> I had defined on my system and that was 16. The Android Handler has been
>>> in the API since version 1
>>> (http://developer.android.com/reference/android/os/Handler.html) so it
>>> should work on any platform.
>>>
>>> I hope I made that clearer rather than, well, vaguer, if that's even a word.
>>>
>>>>
>>>> - Does fork not work with the wifiLock?  It was commented out in
>>>> 0003-MeshService...patch
>>>
>>> That was only commented out because it does not work on the specific
>>> device that I am using for testing. Sorry for allowing that to slip through.
>>>
>>> Please reach out with other questions. I am interested in your feedback,
>>> as always!
>>>
>>> Will
>>>
>>>>
>>>> .hc
>>>>
>>>> On 08/27/2012 04:10 PM, Will Hawkins wrote:
>>>>> Hello everyone!
>>>>>
>>>>> The much-talked-about single SU functionality is ready to deploy. Most
>>>>> of the functionality works through a daemon known as fork. fork is a
>>>>> shell that allows "the user to remotely start a shell, manage jobs, and
>>>>> give input and take output from those jobs". For more information about
>>>>> fork, please refer to the project README file available at
>>>>> https://github.com/opentechinstitute/shell-fork.
>>>>>
>>>>> fork has a Java API that is used to incorporate it into the MeshTether
>>>>> application. The Java API has JavaDoc to explain its usage. To "make"
>>>>> the JavaDoc, use the ant target javadoc, as in
>>>>> $ ant javadoc
>>>>> The resulting files will be in the bin/ directory of the source code tree.
>>>>>
>>>>> Attached to this email are the patches to the MeshTether application
>>>>> that integrate fork. The patches include changes to Java source code and
>>>>> Makefiles.
>>>>>
>>>>> In order for these patches to work, you must first incorporate
>>>>> shell-fork (git://github.com/opentechinstitute/shell-fork.git) as a
>>>>> submodule in the external/fork path.
>>>>>
>>>>> I'm sure that there are parts of the integration that I am forgetting to
>>>>> mention. Please send email and we can hash things out.
>>>>>
>>>>> :-)
>>>>> Will
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Commotion-dev mailing list
>>>>> Commotion-dev at lists.chambana.net
>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
> 