• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root some info,please

@Brian:

Okay, I spent the evening getting some new context options supported (they're the set of six that Chainfire supports in the su binary) to use in testing of the Freeze/Thaw Application function.

I also removed the setting of the LD_LIBRARY_PATH variable export (Chainfire's example didn't use that and my adb testing didn't either), so maybe that'll make a difference? :dontknow:

Also, if you could display the context of the /system/bin/pm file so I could compare with the L preview on my N5:

Code:
$ [B]adb shell[/B]
shell@hammerhead:/ $ [B][COLOR="Red"]ls -Z /system/bin/pm[/COLOR][/B]
ls -Z /system/bin/pm
[B][COLOR="Blue"]-rwxr-xr-x root   shell     u:object_r:system_file:s0 pm[/COLOR][/B]
shell@hammerhead:/ $

I also believe I've got the support for identifying the stock N9 recovery (Identify Current Recovery option) that you could try.

I also supported the flashing of the N9 stock recovery, but I didn't have time to test that on my N5 (I do fake flashes to a work file), but I'll try that tomorrow.

Haven't researched what custom recoveries are out there yet to support the identification of them yet...

Thanks again!
 
@Brian:

Okay, I spent the evening getting some new context options supported (they're the set of six that Chainfire supports in the su binary) to use in testing of the Freeze/Thaw Application function.

I also removed the setting of the LD_LIBRARY_PATH variable export (Chainfire's example didn't use that and my adb testing didn't either), so maybe that'll make a difference? :dontknow:

Also, if you could display the context of the /system/bin/pm file so I could compare with the L preview on my N5:

Code:
$ [B]adb shell[/B]
shell@hammerhead:/ $ [B][COLOR="Red"]ls -Z /system/bin/pm[/COLOR][/B]
ls -Z /system/bin/pm
[B][COLOR="Blue"]-rwxr-xr-x root   shell     u:object_r:system_file:s0 pm[/COLOR][/B]
shell@hammerhead:/ $

I also believe I've got the support for identifying the stock N9 recovery (Identify Current Recovery option) that you could try.

I also supported the flashing of the N9 stock recovery, but I didn't have time to test that on my N5 (I do fake flashes to a work file), but I'll try that tomorrow.

Haven't researched what custom recoveries are out there yet to support the identification of them yet...

Thanks again!

Wow you've been busy Sean!! I don't have PC access right now, but I can at least test the new app. And as for custom recovery, I know twrp is being worked on right now, but there is no custom recovery available yet. I've been followings that pretty closely as it's hard to live without one. :)
 
Okay, looks like you got it fixed, first tested with all contexts off and freeze and thaw both worked: https://copy.com/3eKcRhJacOYM1nlE

Do you still want me to check the nine contexts or are these results satisfactory?

Wow! That's kind of weird...all I did for the non-special (i.e., normal mode) was to remove the explicit export command for the library I thought I had to update/include.

I suppose that could have been the problem...

Lemme build a clean .apk with just the normal stuff and I'll get the flashing stuff built for you, too, if you want.

I'll ping you back tonight! :)

Thank you, again, Brian! Much appreciated!

edit: actually, it would be helpful to know which contexts specially worked...if you could just test the ones that had the "_app" suffix on them, I would appreciate it. Chainfire indicated those specific ones were needed for Java-based code:

All commands that launch Java-based code however must be run as one of the *_app contexts. If you don't, an ART error may be triggered that brings down the entire system. Note that this specific issue does not occur when using Dalvik.

As a (strange) example, let's wipe the interal sdcard, uninstall the com.example.app package, and wipe the Dalvik cache. The following commands would all be piped to a su shell and thus run as root:

toolbox rm -rf /data/media/*
su --context u:r:system_app:s0 -c "pm uninstall com.example.app" < /dev/null
toolbox rm -rf /data/dalvik-cache/*​

I think you've already tested non-"_app" contexts and I'm guessing/hoping you didn't see/get any crashes, but it would be helpful to know which contexts works for the pm command since I'm likely to run into this on other devices.

FYI, on the preview image for my N5, I only had one context that didn't work (I can't remember which it was, but none of them crashed my N5 running Lollipop).

Thanks!
 
Okay Brian,

Sorry for the delay in getting back with you re. this...we had a bit of a crisis at work starting Thursday (and continuing into today) and I worked on my OTA Verifier app last night after getting an email about it crashing (I fixed it :)).

Anyway, I downloaded the the official 5.0 factory image for the N5 and flashed it to my backup device and did some more testing.

Attached is the new v3.8 version of Root Toolkit for Android that I think I can publish pending any issues you might find. Please let me know if you have any new/further issue with the freeze/thaw function.

I basically just removed (commented-out) the test code I did for you and set the context for the pm to use the untrusted_app context that Chainfire recommended and I've found works on the preview image and the current retail 5.0 version (I did remove the "extra" export that I use for versions less than 5.0 that I suspect might have made all of the difference).

Additionally, the support for the stock recovery (identification and flashing) for the N9 should work for you (I did find a small issue I had to fix for that, so if you tested it before it wouldn't have worked).

By the way, how exactly did you root your N9 (Wug's, CF Auto Root, or other/manual)?

Cheers and thanks again for your help!
 

Attachments

No worries, Brian--at this point, I think I just want to confirm that the freeze/thaw function works for you as currently coded in the test .apk attached above (I'm pretty sure (crossing fingers) that it's ready for re-publishing).

Thanks!
 
Working as expected. :)

Awesome and thank you, again, Brian!

I'll get the new version published ASAP :).

Also just saw this from Chainfire: https://plus.google.com/113517319477420052449/posts/jGoDoPPZUdT

SuperSU v2.23 BETA - for immediate testing

I've just added a TWRP flashable ZIP for SuperSU v2.23 to my download server - see the link in the box at the bottom of this post.

I was busy writing the 5.0 additions for How-To SU when an idea struck me that could fix a number of SELinux policy issues on Lollipop, of which previous attempts to transparently work around resulted in failed boots.

v2.23 is the implementation of those workarounds. Please extensively test this version ASAP on your Lollipop (and KitKat) Android's.

A number of root apps that previously would not work may now start working - please post in the XDA thread if so.

However, there could also be negative side effects, so if something stops working that did work with v2.22, please post about that as well.

...

(note that Chainfire mentions in the comments that flashing of a modified boot.img is still needed, so this doesn't yet take care of that)

So it sounds like good news for the future and for devs currently experiencing problems converting their apps to work with the new SELinux paradigm.

Cheers!
 
Interesting... I'm a little confused. I haven't been following development for the last couple of days but as far as I know, there still isn't even custom recovery.

Bear with my developer ignorance, but chainfires original root flashes a patched custom kernel, but from what I understand, his auto root method for "Q" patches the existing kernel.

Now that I've typed that, I guess you're correct, it still requires a patched kernel. The patch just uses different methods depending on root method.

PS. Still not seeing custom recovery anywhere???
 
Interesting... I'm a little confused. I haven't been following development for the last couple of days but as far as I know, there still isn't even custom recovery.

Bear with my developer ignorance, but chainfires original root flashes a patched custom kernel, but from what I understand, his auto root method for "Q" patches the existing kernel.

Now that I've typed that, I guess you're correct, it still requires a patched kernel. The patch just uses different methods depending on root method.

PS. Still not seeing custom recovery anywhere???

Oh, not sure about custom recovery for the N9...I'm wondering if the 64 bit thing is holding it up? :dontknow:

(I'm sure Chainfire wasn't specifically talking about the N9 in his G+ post--I just mentioned it because of the relevance to the context issues and 5.0 root in general)

Yeah, I poked around in the internals of the CF Autoroot for the N5 and it's an amazing piece of work. He's got a binary called supolicy that will actually patch the kernel vs. re-flashing a new one (at least from what I can tell and understand (I'd like to see the source of the program :p)).

You have to fastboot boot (i.e., soft boot) the CF Autoroot image to make it run/install all the goodies under the hood while the system (Android) is quiesced. Pretty neat stuff!

:)
 
Back
Top Bottom