Cover photo
Verified name
379,779 followers|29,794,833 views



Shared publicly  - 
SuperSU v2.74 BETA: Samsung Security Policy Updates, and N Preview 3

Let me just start off by noting that SuperSU v2.74, as well as the previous version 2.72, are fully compatible with Android N Preview 3. So if that is all the information you were looking for, there you have it.

Samsung Security Policy Updates

A few days ago many Samsung users suddenly lost root after their devices received a security policy (SELinux) update. As was to be expected, many posts followed about the evils of Samsung and their breaking of root on purpose. Of course the reality of the situation is far less dramatic: any security policy update using this mechanism would have broken root, regardless of the content of said update.

This issue has been expected to occur for quite some time, but Samsung had not pushed this type of update wide enough before that it could be caught and analyzed.

Now that I've finally been able to play with it, this new version of SuperSU blocks these policy updates completely, and keeps you on the SELinux policy version embedded in the boot image (with SuperSU's modifications).

There are several reasons why the update is blocked, rather than patching it with SuperSU's needed changes:

- Samsung's policy updates are loosely based on provisions inside AOSP to do exactly this, but they have modified it enough that it has become non-standard, and other OEMs may have done the same. As such there is no easy generic way to reliably catch and modify these updates across the board before they are applied.

- It is my understanding that the security policy update mechanism in AOSP has been deprecated as of N. Probably in favor of just updating the boot image altogether (which includes these policies) via the now monthly OTA (and future seamless?) updates. Keeping that in mind, writing a bunch of extra code just to catch this edge-case that will probably not be relevant for more than a few months, seems like a waste.

Fixing lost root due to the security update

In theory, fixing root is as simple as flashing the new SuperSU v2.74 BETA ZIP file in TWRP, or using the updated CF-Auto-Root for your device.

In practice, this will not work for a fair share of users. To re-systemless-root using SuperSU ZIP's or CF-Auto-Root, if you have already been rooted, requires the stock boot image to be restored. Both methods create a backup of the stock boot image before applying root. During testing of this fix however, it became clear that a lot more users than I had expected managed to somehow lose this backup (clearing cache, factory reset, etc).

If this backup is no longer on your device, neither flashing the SuperSU ZIP nor re-applying CF-Auto-Root will fix the issue, as both installations will fail.

If you happen to have a TWRP backup of the boot image, you can restore that. Otherwise, the only solution is to find your stock firmware on a site such as, and either flashing it completely, or extracting the boot.img and manually flashing that, before re-rooting.

For completeness sake, note that you can get rid of the security policy update by deleting the /data/security/spota folder, if you have any way of doing that - which most users who lost root will not.

Ramdisk backups

To reduce the impact of lost boot image backups for the future, starting v2.74, the SuperSU ZIP installer (and thus also CF-Auto-Root) will backup changed files in the boot image ramdisk to the ramdisk itself.

While this backup is not good enough to restore your original boot image to the exact state required to perform an incremental OTA, it should be good enough to be able to re-flash SuperSU even if the full boot image backup got lost - though I make no claims as to what happens if you mix it with custom kernels.



SuperSU BETA thread on XDA:

SuperSU subforum on XDA:

All CF-Auto-Root's have already been updated with this new version of SuperSU:

- supolicy/sukernel: Prevent security updates to SELinux from being applied
- sukernel: backup and restore modified ramdisk files, to be able to re-root if boot image backup got lost
- ZIP: Only show TWRP warning on TWRP v2.x
Live wallpaper and daydream displaying the latest and greatest imagery from, highly configurable. SuperSU. The best Superuser access management available ! DSLR Controller. Control your Canon EOS DSLR from your phone ! A Game Of Threes. Addictive game - free! Downloads served: ...
Jonathan L's profile phototalha ansari's profile photoPatrick Meloni's profile photomurat yarali's profile photo
Cok sacma hic bir ise yaramiyor program 
 ·  Translate
Add a comment...


Shared publicly  - 
FlashFire v0.33: backup/restore through ADB, even over Wi-Fi

Today's FlashFire update brings a major new feature and many smaller fixes and improvements.

adb backup/restore, using USB or Wi-Fi
By utilizing adb, you can now stream backups directly to and restore them from your computer. This also supports adb over Wi-Fi.

To backup, create a new backup action, and as location choose "Android Debug Bridge (ADB)" instead of the default "Internal Storage", and select the partitions you want to backup.

To restore, create a new restore action, and tap the USB icon at the backup selection screen. Then select the partitions you want to restore if present in the backup.

After tapping the Flash button, you will be presented with on-screen instructions as needed.

Please note that these backups are the same as the ones stored on your Android device, but wrapped in a ZIP container in a specific order. So while you can unZIP them and place them on your Android device to use, as of yet you cannot just ZIP up an existing backup from your Android device and restore it through adb.

Also note that while we are using the adb backup/restore commands, these backups are not in the same format as using adb backup/restore normally. We are just hijacking this command for convenience.

Adopted storage
There have been quite a number of changes in how adoptable storages are handled this version. Apparently there were some nuances to it that I previously misunderstood, which caused some strange behavior. This should now be fixed.

It is important to note that FlashFire should always treat your Internal Storage as your Internal Storage, and your Adopted Storage as Adopted Storage, even if you have migrated between the two so normal applications see your Adopted Storage as Internal Storage instead.

This means that if you select Internal Storage as a backup location, it will always go to your actual Internal Storage, and never to your Adopted Storage. If you want the latter, you need to select it specifically, that's why the option exists.

While this might seem perfectly logical to some, during development and testing of this feature, some users expected otherwise, hence the emphasis.

Other noteworthy changes
App startup performance has improved significantly, especially for users with many backups on their storages.

Back key behavior has changed somewhat throughout the app. This should cause less accidental app closes.

During operations, progress information is now shown more often, and more detailed. The current file that is being backed up or restored may be shown now where it wasn't before, as may total bytes read/written/transferred, the speed at which this happens, and how long it has taken so far.

Additional partition types are now supported, and additional OTA file locations are now automatically detected.

Last but not least, the embedded SuperSU has been updated to v2.72 BETA, and it outputs less information when being applied through EverRoot, giving you a better opportunity to see status information about the other actions you had FlashFire perform.

While there are many features and fixes still on my to-do list - yes, including ODIN backups, stop asking! - after this update I think the first next thing is getting some documentation in order and taking the app out of Play BETA, so people can download and use the app without jumping through hoops.

Please note that a lot of code has changed this release, and new bugs may have been introduced. Please report them to the XDA thread when you run in to them!

Google Play's awkward BETA program opt-in:

Direct APK download:

Discussion, bug reports, feature requests, etc
XDA thread:

- Add support for backing up to and restoring from ADB, through USB or Wi-Fi (special ZIP format)
- Completely reworked progress code, more info is shown in more places now (current file, speed, progress)
- Improved back key handling
- Improved app startup performance
- If sdcard is adopted, reflect that in location display name
- Fix adopted SD card sometimes not showing up in mixed partition mode
- Attempt to identify external sdcard (rather than calling it USB)
- Adjust storage location display order
- Add warning when using adopted storage
- Rewrote file creation routines to cope better with adopted storages
- Fix reboot card popup title
- Refactor shell commands as root
- Change install location to internal-only
- Fix backup of internal storage not skipping backups in some cases
- Adjust ZIP parser so it can cope with Samsung FOTA ZIPs
- Added warning for Huawei users about brickability
- Add OEM partition to TWRP emergency restore
- Fix backup/restore per-file progress freezing
- Archives: Add suppport for Huawei's UPDATE.APP format
- OTA: Add detection for Samsung
- OTA: Add detection for Huawei
- OTA: Add detection for HTC
- OTA: Add detection for Letv
- OTA: Add multi-zip-file capability
- Partitions: Add various Tegra-specific partitions
- Partitions: Add various Mtk64-specific partitions
- Partitions: Add various Huawei-specific partitions
- Partitions: Add various Pixel-C-specific partitions
- Partitions: Add generic Factory Reset Protection partition
- Partitions: Add support for eMMC boot and general purpose partitions
- Partitions: Attempt r/w unlock before writing
- EverRoot: Updated embedded SuperSU to v2.72 BETA
- EverRoot: Use LESSLOGGING mode, reduces SuperSU output
Downloads served: FlashFire: 44 415. This file: 0. Maintaining all my projects takes a lot of work, please consider donating for my efforts, and/or trying some of my apps! Follow @ChainfireXDA. Follow me on Google+ Download FlashFire-v0.33-20160511115223.apk. Copyright © 2011-2016 - Chainfire.
Jonathan L's profile photoAmarmmm Mmm's profile photoNick Gatti's profile photo
Hey, flashfire crashes on my Fire. Won't even open. any ideas?
Add a comment...


Shared publicly  - 
FlashFire v0.32: Fastboot flashable backups

The major new feature of today's FlashFire update is the ability to create backups that can be flashed back to the device with fastboot. This will allow you to restore your phone from your computer without booting Android or even a custom recovery. This is a new and experimental feature, and as such there are a number of ifs, buts, snags, and caveats.

Only the main Android-related partitions are able to be backed up: boot, recovery, system, vendor, oem, userdata (including internal storage), and cache. Radio/modem partitions need some further investigation and testing, while bootloader (and other not mentioned) partitions will probably never be supported.

As the userdata partition generally contains both /data and internal storage, you should be aware that if you choose not to backup internal storage, restoring the userdata partition through fastboot will leave you with an empty internal storage.

As with backing up the internal storage normally in FlashFire, backups and other files from FlashFire, TWRP, CWM and MultiROM are skipped.

The backup of userdata is currently always in unencrypted ext4 format (even if you are currently running encrypted f2fs). If you restore it, you will end up with an unencrypted ext4 device - a pro for some, a con for others. You need to be aware that stock Marshmallow+ kernels may refuse to work with an unencrypted userdata partition. A SuperSU-patched boot image should work fine though, and chances are, that is included in your backup. Both encryption and f2fs support are under investigation for future versions.

Fastboot backups are truly meant to be restored from your PC using fastboot. While you can 'install' the backup ZIP file using the '_Flash firmware package_' option, that currently does not support flashing the userdata partition, which is usually the most important partition to backup/restore. There may be support for this in the future, though.

The backup itself is a ZIP file containing partition chunks (similar to Motorola's sparsechunk format) and a flash-all.bat file to perform the restore. The commands in that batch file should also work on Linux and OSX, but regardless of platform, the fastboot command needs to be on the PATH, and support the -u switch (which all recent Android SDK versions do). Obviously, your bootloader also needs to be unlocked for the flash to work.

Last but not least, this feature has only been tested with a handful of devices, while there are a great many devices out there that support fastboot. It might not work well or at all for your device.

Other noteworthy changes
When flashing a ZIP or OTA, there is now the option to '_Preserve recovery_'. This will backup your current recovery image before starting the action, and restore it afterwards. This option is automatically enabled if FlashFire detects you have TWRP or another custom recovery installed. With this feature enabled, you can have TWRP survive an OTA flash, even if FlashFire restores the stock boot and recovery to let that OTA succeed.

A pretty severe issue with SurfaceFlinger has been identified and worked around. This issue could cause FlashFire to black screen indefinitely rather than performing the flash or rebooting. This might not fix all black screen issues, but it will fix some.

I've also finally gotten round to implementing the Credits listing, which details the used libraries and binaries and their authors and licenses. I'll cower behind the BETA tag for not taking care of this sooner.

Google Play's awkward BETA program opt-in:

Direct APK download:

Discussion, bug reports, feature requests, etc
XDA thread:

- Exclude multirom folder from internal storage backup as well
- Ability to create fastboot flashable backups
- Use proper ioctls for partition and block size detection
- Added option to backup recovery before installing ZIP/OTA and restoring it afterwards (automatically enabled when a custom recovery is detected)
- Added a watchdog to detect SurfaceFlinger crashes, fixes some black screen issues
- Prevent repeating OTA flash suggestion on rotate
- Added credits listing
Downloads served: FlashFire: 34 027. This file: 0. Maintaining all my projects takes a lot of work, please consider donating for my efforts, and/or trying some of my apps! Follow @ChainfireXDA. Follow me on Google+ Download FlashFire-v0.32-20160420152035.apk. Copyright © 2011-2016 - Chainfire.
David el crack el mero crack's profile photo‫پژمان صادقی‬‎'s profile photoVincent Gilbert's profile photoAlassane Kabore's profile photo
Cest propre
 ·  Translate
Add a comment...


Shared publicly  - 
SuperSU v2.71 BETA released, CF-Auto-Roots updated

Really isn't much to mention about this, other than that all the changes for N Preview have been merged with the main BETA releases, where they were two separate releases before.

Additionally, all CF-Auto-Roots have been updated with the new version, and a lot of them have seen base firmware updates as well.
ezy fahrezy's profile photoShine Stones's profile photofransiskus xaverius lendi mangu tana's profile photoChainfire's profile photo


Shared publicly  - 
CF.lumen v3.66 released

Today brings a minor update to CF.lumen, fixing some issues for Tasker users and fixing a minor performance snafu.

It may take a couple of hours for Play to give you the new version, but as always it is already available from the XDA thread here:

- CF.lumen driver: smoother filter switching
- CF.lumen driver in Performance mode: fix disable hardware overlays option sticking when CF.lumen is disabled
- Tasker: fix black screen on filter selection
- Tasker: fix brightness change on filter selection
CF.lumen adapts the colors on your Android device based on the position of ...
Banan PL's profile photoЛавр Фаверо's profile photoMatthew Schwarz's profile photoDaniel Neergaard's profile photo
Would it be possible to have an option to adjust the 60 minute disable and wake timouts? Perhaps wake/disable until i enable it or just adjust it to 120 mins. or w/e. Say im active in a game and the sleep mode turns on, some games does not allow one to open the notifications to set wake or disable
Add a comment...


Shared publicly  - 
S7 and S7 Edge (Exynos) CF-Auto-Root available

CF-Auto-Roots for G930F and G935F are available at the repo -

These will very likely also work for other Exynos-based S7 models.

Before flashing, make sure you have enabled "OEM unlock" from "Developer Settings" !

Note that CFAR's display code isn't yet compatible with the S7, as such, there is no output on screen. This means that after flashing with ODIN, the device will only show you the S7 logo, and it seems like nothing happens. Just leave the device alone for 5 minutes. It'll reboot a few times, then boot into Android, but now you have root. 

If it still doesn't do anything after 5 minutes, something has gone wrong, and you should probably reflash your stock boot.img and recovery.img.
When newer firmwares are released for a certain device, sometimes that firmware includes new bootloaders that prevent kernels based on the old firmwares from booting. This usually coincides with a transition to a newer Android version. In that case, the CF-Auto-Root for download here may no ...
Reyad Abdessemed's profile photoLuis Haddad's profile photoOmair Zeeshan's profile photoDarko Demic's profile photo
+Chainfire Question does this removes ability to perform Samsung software updates in the future or I can install updates manually?

Add a comment...
In their circles
1 person
Have them in circles
379,779 people
Luizfelipe Bleidao's profile photo
Ed Baz's profile photo
Roderick Siebel's profile photo
Sabah Uddin's profile photo
Aashish kumar's profile photo
Jesse Green's profile photo
Kang Il Lee's profile photo
Choirul Anwar's profile photo
sai kiran's profile photo


Shared publicly  - 
LiveBoot v1.30: Android N Preview 3 compatibility

This update brings nothing more or less than compatibility with Android N Preview 3.

Play will need a few hours to process the update and start distributing it, in the mean time you can grab the APK from the thread on XDA:
胡天翔's profile photoPACMAN PHOTOg's profile photo‫الياس عبدالله‬‎'s profile photoVicente Lama Gonzalez's profile photo
Add a comment...


Shared publicly  - 
SuperSU v2.72 BETA released

This is a relatively minor update. Support for the patching ChromeOS-wrapped Android boot images has been added (Pixel C), some logcat and fsck issues were fixed in the SELinux policy, and some flags have been added to the ZIP installer.

Force encrypt

Some recent devices do not get a signal - for reasons yet unknown - unless /data is encrypted. The SuperSU ZIP installer by default removes the forceencrypt flag from fstab, so you can run your device unencrypted if you want to. In some cases this may cause you to run unencrypted while you want to be running encrypted, such as on these recent devices. That is what the KEEPFORCEENCRYPT flag is for.

I am open to debate (in the BETA thread on XDA) as to whether the situation should be switched around, keeping the forceencrypt flag enabled by default, and have removing it be the case that requires extra action. It seems to me like those who want to run decrypted may be the more advanced users as well as the minority.

To clarify: the situation right now is still the same as in 2.71, there is now just the option to change the behavior. The point of discussion is whether that option should become the default in the future.


Not a day goes by since the release of 2.69 - sometimes not even an hour, or a full page in the thread - that somebody doesn't complain or ask about ES File Explorer or Secure Settings or whatever root app not getting root.

I want to emphasize again that these are bad apps that are hardcoding the path to the su binary. This has always been a bad idea and I have been warning against it since 2012.

In the early days of systemless root a compatibility mode hack was enabled by default, but this has been disabled since 2.69. It will not come back, because it's a bit of a dirty hack, and I'm not going to keep forcing millions upon millions of users running that hack just for a handful of outdated apps to work.

You can manually re-enable that compatibility mode by setting the BINDSYSTEMXBIN flag before re-flashing SuperSU, see

I suggest writing the authors of these apps to inform them that their apps will no longer work with SuperSU on Marshmallow by default, and ask them to fix their code. Said fix is generally one line or less, so there really isn't much of an excuse to not just fix it.



SuperSU BETA thread on XDA:

SuperSU subforum on XDA:

- Add support for ChromeOS boot images (Pixel C)
- supolicy: Fix logging to logcat for some processes on some firmwares
- supolicy: Fix fsck of /data/su.img being denied on some firmwares
- ZIP: Also read flags from /cache/.supersu (aside from /data/.supersu and /system/.supersu)
Live wallpaper and daydream displaying the latest and greatest imagery from, highly configurable. SuperSU. The best Superuser access management available ! DSLR Controller. Control your Canon EOS DSLR from your phone ! A Game Of Threes. Addictive game - free! Downloads served: ...
Rodrigo Luiz's profile photoCanyn Latham's profile photo‫كمال أحمد‬‎'s profile photoaBaDy The Best's profile photo
Add a comment...


Shared publicly  - 
FlashFire v0.31 released

Most of todays update is compatibility related (again), fixing issues with various popular update ZIPs.

Additionally, lz4 compression (used when creating and restoring backups) is now multithreaded, which can provide a nice speed-up.

For Samsung users, generating a .tar.md5 with bootloaders and modem to flash through ODIN now includes partitions FlashFire cannot see or detect. This should fix missing bootloader issues on for example the S6.

*warning warning warning*
Something less fun to announce is that due to a bug in partition detection, some backups created in FlashFire v0.26 through v0.30 cannot be restored by 'installing' them in TWRP. This does not affect all backups, but it is hard to tell which ones will or will not work.

Of course, all of these backups are still restorable in FlashFire itself, but if you rely on TWRP for emergency restore if you mess up your system, you should create a new backup for this purpose.

Google Play's awkward BETA program opt-in:

Direct APK download:

Discussion, bug reports, feature requests, etc
XDA thread:

- Exclude usbStorage folder from internal storage backup as well
- Switched to multi-threaded lz4 implementation (much faster backup/restore)
- Replace gzip with pigz in flash mode
- Set umask to 0 in flash mode
- Use tmpfs for /tmp
- Fix several other issues preventing flash mode from starting (reboots)
- Fix bug in TWRP restore listing (warning: old backups may not restore in TWRP !)
- Fix files present in firmware packages not being shown if the partition cannot be found
- Fix sdcard daemon running multiple times and eating CPU for no reason
- AROMA: prevent reboot call
- AROMA: only do framebuffer emulation if AROMA is actually detected, to prevent running into
‫يوسف عبدالوهاب‬‎'s profile photoJose 79's profile photoAyoub Haddad's profile photoJames Fortenberry's profile photo
Free download links to weblogs that is awesome
Add a comment...


Shared publicly  - 
FlashFire v0.30 released

Another FlashFire update mostly improving compatibility.

AROMA based installers should now work across all devices. To accomplish this, FlashFire emulates the Linux framebuffer driver. While it appears to work fine, you may notice the graphics aren't as smooth as running AROMA from recovery - but at least it works. And if it doesn't, please report it in the XDA thread :)

A number of devices that would previously reboot instead of performing the requested action, should now be compatible. This includes a number of LG and LeTV devices.

Yet more external storage configurations are supported - including StickMount based -, and the backups listing will now also show you where they are stored.

The embedded SuperSU version has also been update to v2.71. There's a noticable performance increase in flash mode startup if you run FlashFire on a system with SuperSU v2.71 installed.

Google Play's awkward BETA program opt-in:

Direct APK download:

Discussion, bug reports, feature requests, etc
XDA thread:

- Exclude TitaniumBackup folder from internal storage backup as well
- Add location (internal storage, sd card, USB drive, ...) to backup listing
- Improve compatibility with StickMount-based USB mounts
- Fix a number of issues that could cause reboot while switching to flash mode
- Fix display brightness on some devices
- Framebuffer emulation for AROMA Installer (pretends to be a debugger, hijacks graphics calls)
- Fix bug where cache partition could lose data
- Complete refactor of flash mode code
- Improve Samsung CSC handling
- Fix bug where internal storage mounting could fail if external (sdcard/usb) storage present
- Update embedded SuperSU to v2.71
Mitch Barber's profile photoTRAN TRONG HUYNH's profile photoJoshua Pankhurst's profile photoBobby Barrick's profile photo
Add a comment...


Shared publicly  - 
FlashFire v0.29 released

Today's update of FlashFire is mostly a compatibility update. A bug in Android N itself that prevented OTAs from flashing has been worked around (you may still see incorrect size listings of 2048 MiB in some places, though), and there have been quite a few modifications to partition detection and external storage handling (portable and adopted sd cards, as well as USB).

Both the app's startup time as well as the time it takes to switch from Android to flashing mode have been reduced. The latter will be even faster when combined with the soon-to-be-released SuperSU v2.71.

Feature wise, an option to format /cache has been added to the Wipe action, to fix /cache partitions that are the wrong size and prevent OTAs from flashing. Additionally, the internal storage can now also be backed up, though it will skip FlashFire and TWRP backup files.

Last but not least, a setting has been added to allow primary and secondary bootloader partitions to be flashed (on devices where this is possible, such as most Nexus devices). This is extremely dangerous - any failure may hard-brick your device - don't touch it if you don't know what you are doing.

Google Play's awkward BETA program opt-in:

Direct APK download:

Discussion, bug reports, feature requests, etc
XDA thread:

- Fix some compatibility issues with N Preview
- Fix app_process causing a reboot during startup
- Fix bug which could cause flashing /system to freeze
- Improve partition detection size accuracy
- Reduce app startup time
- Reduce time taken to switch to flash mode
- Add option to format /cache (wipe action)
- Improve external sdcard compatibility
- Improve adopted storage compatibility
- Improve USB drive compatibility
- Add additional OTA paths for NVidia
- Improve partition platform detection
- Add support for backing up internal storage (excludes FlashFire, TWRP and CWM backups)
- Fix error when opening bootloader image not wrapped in an archive
- Add setting to enable flashing primary and secondary bootloaders (automatically disabled)
- EverRoot: "Enable ADB" no longer enabled by default
Zaki Manzanza's profile photoK-D Fredrick's profile photoSebastijan Kocman's profile photoChainfire's profile photo


Shared publicly  - 
N Preview: Surviving Your Trip To Mount Doom

Preface: What's in the box?
The three boxes on Android are toolbox, busybox, and toybox. These boxes provide implementations for various basic unix commands - similar to those GNU Core Utils provides on various Linux distributions.

toolbox was until recently the standard Android implementation. busybox is pretty much the standard box outside of Android, GPL-licensed, and has been ported to Android by many. toybox is a BSD-licensed alternative to busybox created by a former busybox maintainer. toybox first appeared on Android in M, and is slowly replacing the toolbox implementation for various commands.

These commands are mostly used by root apps, device scripts, and adb shell / terminal emulator users.

Consistency is key
Those who have been following me for a while know that I am not a fan of busybox. This is mainly because many users install it in such a way that it overrides the default commands.

Many root apps need to execute commands provided by these boxes. While the base command is generally the same, the accepted parameters, exact working, and output, will differ between implementations, and different versions of those implementations.

For example, around 4.3-ish days, there were at least three different versions of busybox common, with different levels of SELinux support, and inconsistent behavior for common commands.

Of course, a developer can call toolbox explicitly, and work around a user using an overriding install of busybox. Exact toolbox implementation can be matched with currently running Android version, and is thus easier to work with for developers. Apps with special needs usually come with their own copy of busybox so they can predict exactly what a command does - but this is overkill for most apps.

Since toybox's introduction in M, calling toolbox explicitly stopped being reliable, as commands were being removed from toolbox as the default implementations shifted to toybox.

Unlike toolbox though, toybox provides a list of supported commands, so there was still a way to avoid the dreaded busybox, and get to a more predictable (even if not generally consistent) implementation, be it toolbox or toybox.

At this point, you might be starting to suspect that supporting all this from a root app supporting years old Android versions up to the most recent is a painful affair.

Mount Doom
(or: why apps fail to remount /system read/write)

And so, we finally arrive at the perils of the mount command. Even on M, toybox had a mount implementation. In many cases, this implementation would just segfault at you without doing any work. No matter, toolbox still had its mount command, and that still worked.

Unfortunately, on N Preview, toybox mount has replaced toolbox mount as the default implementation, and even worse, toolbox mount has been removed, so you cannot fall back to it. While toybox mount seems to have gotten rid of its saga of segfaults, it still doesn't actually work all that well. Not nearly as well as the toolbox implementation it has replaced, at least.

One of it's issues is that it doesn't understand relatime - and that's not even a joke. As most mounts are relatime by default, when a remount is performed, first it checks the current mount flags, finds relatime, and then panics.

In SuperSU v2.70, this has been countered by setting the (by default) read-only mounts to use noatime, which toybox mount does understand.

With this fix applied, the following remount commands will work:

((/system/bin/)(toybox )mount -o rw,remount /system
((/system/bin/)(toybox )mount -o rw,remount /path/to/device /system

Unfortunately, this does not cover all the popular forms of the mount command as used by various apps, and as such, many root apps will fail to remount /system, and thus will not be able to modify it. These apps will need an update, as I don't see an easy way to work around this.

Let's start with the /path/to/device parameter. The actual (g)libc/bionic mount(2) syscall that is ultimately called generally ignores this parameter completely in case of a remount, but various mount utilities do not.

For example, on Android 2.x the parameter had to be both present and correct, while on 3.x and early 4.x, it only needed to be present. On later versions, it can be present or omitted. As a shortcut, many apps actually use:

mount -o rw,remount /system /system

With toybox, if you specify the /path/to/device parameter, it has to be correct again as well. An interesting note on that is that toybox's mount command's output differs from toolbox as well, and may actually resolve symlinks in its output - so you actually need to examine /proc/mounts instead to get the correct /path/to/device (otherwise you'll get a busy error).

As toolbox prefixes will now also no longer work to perform the remount, the following commonly used mount constructs by root apps will fail:

(/system/bin/)toolbox mount -o rw,remount /system
(/system/bin/)toolbox mount -o rw,remount /path/to/device /system
(/system/bin/)mount -o rw,remount /wrong/path/to/device /system

If you're a root app dev, you know what you need to fix. If you're a user, this is the reason many root apps will fail manipulating /system on N Preview right now.
John L Galt's profile photoAbdul Munim Kazia's profile photoabdullah waseem cheema's profile photoKhalidh Khaleefa's profile photo
انا عندي مشكله في الاكس مود
 ·  Translate
Add a comment...
In their circles
1 person
Have them in circles
379,779 people
Luizfelipe Bleidao's profile photo
Ed Baz's profile photo
Roderick Siebel's profile photo
Sabah Uddin's profile photo
Aashish kumar's profile photo
Jesse Green's profile photo
Kang Il Lee's profile photo
Choirul Anwar's profile photo
sai kiran's profile photo