Profile cover photo
Profile photo

Post is pinned.
PSA: There is no support on G+

While Google Plus is a nice medium to share information, it is utterly unsuitable for any form of support.

All releases have their own discussion threads on, which are referenced in most posts here. If you need assistance, want to file a bug report, or discuss anything related to a release, please go the relevant XDA thread.

You will not receive any support here on G+.

Additionally, all posts should be English only.

FlashFire v0.73 released

This week's update to FlashFire brings a few bugfixes as well as feature improvements. The highlights:

Magisk support
Support for Magisk has been significantly improved with this release, especially for flashing incremental OTAs. This should now work mostly the same as when SuperSU is used: pretty much fire and forget.

Limitation: this requires Magisk v14 and its installation being done through TWRP or the Magisk app - it doesn't work with pre-patched boot images.

For now EverRoot still injects SuperSU to keep root though, so if you want to stick with Magisk you need to disable the EverRoot feature and add a ZIP flash action with Magisk's installer ZIP.

Backup excludes
You can add two text files in FlashFire's folder on the sdcard that list files and folders you do not want to include in backups. Examples are dalvik-cache, Chrome's browser cache, your tv shows and music collection, etc.

Users have requested a solution like adding a .nobackup file to folders they want to skip, but that wouldn't work for files in /data, and scanning the entire internal storage to collect those files can be an expensive operation. So I opted for this solution instead.

Read more here:

ZIP association
FlashFire can now be used to open ZIP files directly from some file managers and Chrome's download listing. An opened ZIP will appear as a ZIP action card in FlashFire's UI. As a lot of apps tend to open ZIPs themselves (such as Android's standard Downloads app) rather than find which apps can open it for them, so FlashFire has also become a recipient for Android's Share feature that you can use instead.

FlashFire will attempt to resolve the real location of the ZIP file to where it is stored in /data (including internal storage). If this does not succeed, FlashFire cannot use the file. This also means that ZIPs stored on real sdcards cannot be used this way.

File-based encryption
Some more issues with devices that use file-based encryption (such as the Pixel) have been found and corrected. These primarily related to restores and wipes.


Google Play:

Direct Download:

Discussion thread on XDA:

- A/B OTA: Support for yet another streaming variant
- Magisk support: Fix some black screen issues
- Magisk support: Much improved OTA flashing compatibility (excluding A/B devices)
- SuperSU: Updated embedded SuperSU version to v2.82-SR4
- Backup: Exclude paths from backup with /sdcard/FlashFire/userdata_excludes and ./internal_storage_excludes
- Restore: Fix issue where FBE keys sometimes weren't restored
- Wipe: Add option to not wipe files from internal storage that aren't backed up
- ZIP: Open ZIPs from file managers and (Chrome) downloads directly, or share to FlashFire (file must resolvable to reside on /data)
- Adjusted timebomb for non-Pro users to 2018-04-01

Post has attachment

Stock boot and recovery images
For years I've thought it would be useful to have a place where you can grab stock boot and recovery images. Planned to build it long ago, but you know how plans go. This site now hosts my entire stock boot/recovery collection (some 250-ish GiB right now), so that's at least a start.

This (and auto-updating root images, auto-grabbing latest OTAs, etc) was supposed to become a feature in FlashFire, but with Google's recent ban on Play store apps downloading binaries (which I expect would cover this) I'm not really sure what's going to happen there. Perhaps a sideloaded add-on, perhaps nothing.

Of course, my own collection is mostly comprised of Samsung and Google firmwares, and the scrapers are currently focused on those. If someone knows reliable sources of stock firmwares for other brands, let me know in the XDA thread.

Users can add stock boot and recovery images manually, after logging in with a Google account. As this is a possible avenue for abuse, I'm keeping a close eye on it, and should it be abused I'm shutting it down.

Image information
Aside from the images itself, the site also keeps track of quite a few properties of the firmware themselves, including the properties from the images, so developers can review them without having to download them all.

Useless to most, but to devs like me it comes in handy now and again.

The CF-Auto-Root repository ( ) is very old and very static. It was manually updated (though of course based on scripts) every once in a while.

I've wanted to further automate it for years, and I finally got around to it earlier this year. This is now incorporated into this site, and you can generate a CF-Auto-Root package from most firmwares listed.

When generating a CF-Auto-Root packages, you are now also able to configure all sorts of SuperSU-related options in the process, such as install type, encryption options, SELinux modifications, and including suhide.

Other packages
CF-Auto-Root is really just an automated ZIP installer, that currently installs SuperSU. In theory it can be adapted to install other packages as well. This might become a thing in the future, but it is not implemented right now.

I thought this was as good an excuse as any to finally do something in Python and gain some more experience there, and thus most of the site is indeed built in Python3 (thank or blame Jeff Corcoran). It's not a particularly fast site though...

There is some Java intermingled with the Python. The firmware parsing is code is an adapted version of the code written for FlashFire.

The Python parts are built from scratch and job-based, I'm fully expecting some things to break down a couple of times over the next few days, so keep that in mind.

Completely unsure. Maybe it'll grow. Maybe an OEM will have it shut down. Maybe I'll get tired of paying for the bandwidth. Right now this is striking through one of the items on my bucketlist of code.

Mobile version and app
There is currently no mobile version and app for the site. As stated above, that was originally intended to be part of FlashFire. It makes for a somewhat awkward landing page right now if you don't include the desktop subdomain, but the .mobi TLD has rules :)


Discussion thread on XDA:

Post has attachment
SuperSU v2.82-SR4 released

This minor update fixes several edge-cases encountered during the rooting process.

There is no immediate need to update from SR3, because if you were experiencing any of the problems fixed, you wouldn't have root :)

The exception is an SELinux policy fix that should only be relevant to Samsung devices running stock Oreo, which I sincerely doubt you are using right now...

This is really just the public ZIP release for fixes to SuperSU that will be incorporated in the upcoming CFAR (CF-Auto-Root) refresh.


Direct ZIP download:

Discussion thread on XDA:

- ZIP: Fix an incompatibilty with CFAR
- ZIP: Fix slot detection breaking if no /vendor present
- ZIP: If unmounting fails, retry lazily
- sukernel: Fstab patch: fix case where verify removal could break slotselect
- sukernel: Adjust system_root cpio import
- sukernel: Detect and use stock boot image backups created by other tools
- supolicy: Add some Oreo policies
- suinit: Fix boot case where bootloader unexpectedly doesn't enforce dm-verity

SuperSU hits 100 million downloads on Google Play

AndroidPolice broke the news that SuperSU broke the magical 100 million users barrier on Google Play last night.

As I understand, these are unique Google accounts over the lifetime of the app. My own servers count another 160 million downloads, and external sites serve SuperSU downloads as well, but obviously you can't just add these numbers together.

Then there's the fact that many users will have used multiple different Google accounts over the years, but there are also untold millions of devices (especially in Asia) that do run SuperSU but do not run Google Play.

So, the true number of users over the app's lifetime is not really knowable, but I would guess it is indeed somewhere around that 100 million mark. Of course, this number does not represent active users today - years ago when I had access to those numbers, they were between a quarter and a third of the total listed.

Either way, I'm grateful to be lucky enough to see a milestone like this reached for something I made, and a little proud too! A heartfelt thanks to everyone who has supported me and my work over the years - it would not have been possible without you.

Post has attachment
500 Firepaper updated to v2.80

A new version is now starting roll out through the Play Store.

If you're an existing user you will no doubt have noticed the app stopped working recently. On August 21, the app's 500px API key was blocked by 500px. Of course luck would have it this was the very same day I left on vacation, and also the same day Android Oreo was released. I returned last weekend and started investigating the matter.

I was able to get in contact with a platform engineer over at 500px, who informed me that 500 Firepaper's massive bandwidth use was no longer something they were able to support. Not completely surprising, as 500 Firepaper downloads batches of high resolution imagery several times a day. Multiply that by tens of thousands of users, and you can probably imagine this puts some strain on their pipes. I have always expected they'd pull the plug on it because of this at some point, I'm actually surprised it took this long.

As advised by said platform engineer, I have made some major changes to the caching and image selection algorithms in 500 Firepaper:

API call rate limiting
The number of API calls to 500px servers has been significantly reduced.

Daily quota
There is now a hard limit on the number of images that will be pulled from 500px's server every day. Older versions would keep pulling fresh images if you were on an unmetered connection (such as Wi-Fi) and had a nearly full battery or was charging the device. Especially for users with agressive image refresh settings, this could burn through a lot of bandwidth in very little time.

Cache period extension
I have been granted permission by 500px to let the app cache imagery for 7 days. The 500px terms of service normally limits developers to 24 hours, which limited the usefulness of caching.

As this change allows us to cache 7 times as many images, the default cache size setting has increased accordingly in 500 Firepaper's settings - if you are using a lower range device with limited storage, you may want to reduce the cache size now used. I've also preset the orientation bias to 85% portrait to improve cache efficiency for the average user, if you use your phone in landscape a lot, you may want to adjust this setting as well.

Of course, combined with the daily quota, this means that the cache will take up to a week to reach an optimal fill. You will gradually be shown more different images as the days go by.

Display order randomization
Previously, the app showed you the images from the cache that you had seen before the least number of times. If you were away from an unmetered connection for a while, this meant you usually kept seeing the same images in the same order over and over again.

As the app is now becoming more cache-reliant and downloads less truly fresh images, this situation would become more common. Additionally, the algorithm would strongly favor the images downloaded today versus mixing in images cached from the past week.

To mitigate this, the image displayed is semi-randomized from the entire pool of cached imagery, with a slight but noticable bias towards more recently downloaded images. This should provide with a more dynamic display.

While these changes will for some users strongly reduce the number of fresh images (images you have never seen before) 500 Firepaper will bring you, it is my hope that it is still fresh enough for the average user.

This is an attempt to reduce 500 Firepaper's bandwidth usage to a level acceptable to 500px. It remains to be seen if the update actually succeeds in achieving this. 500px will be tracking the app's usage, and even with these changes they may well decide to shut it down (again) at any time.

If they do so, I'm not sure where this will go. I feel that if I reduce bandwidth usage (and thus freshness) even more, it destroys the idea of what 500 Firepaper was supposed to be.

Of course, 500 Firepaper has lost a significant portion of its users due to not being operational for a month, so that alone reduces bandwidth usage by a large margin, which may be good news for those still wanting to use it :)

I've gotten some comments from users saying they would be willing to pay for the bandwidth use. While there are certainly some users willing to do that, we already tried an in-app-purchase with revenue sharing before, and the funds raised then were factors less than the funds required. There's simply not enough people willing to pay for something like this, so that is a dead end.

Other apps
Some users have been switching to other apps that do similar things. Obviously, if they are also using the 500px API, and if they become as popular as 500 Firepaper, and they provide you with the same freshness of images, it is only a matter of time for those apps to suffer the same fate. I'm not saying you shouldn't switch to whatever works for you (because you should!), it's just something you should keep in mind.


500 Firepaper on Google Play:

Discussion thread on XDA:

- New API keys
- Grand algorithm reworking:
--- API call rate limiting
--- Daily quotas
--- Cache period extension
--- Display order randomization
- Fixed bug where images would auto-change for a few seconds

Post has attachment
FlashFire v0.72 released

This update is currently rolling out on Google Play.

Another day, another update. Minutes after the release of v0.71 yesterday, two new OTAs were received on my 5X and PixelXL respectively. Both of these slightly different than the OTAs seen before (it would be nice if Google didn't reinvent the OTA system every other month...).

In case of the 5X, the problem was simply a different marker than previously seen that signaled OTA download completion. The fix was a one-liner.

The OTA for the Pixel (XL) however was of the new A/B streaming kind. While this type of OTA has been documented by Google already, I had never encountered one, and thus FlashFire did not support it. After some hours of coding this one works as well now, but with a sample-size of one we'll just have to see if it keeps working for the October update.

Additionally, some users noticed an issue with the Wipe action when doing a wipe of only the dalvik-cache. Some unrelated files were deleted by accident, which on some devices could cause FCs or even a boot-loop. This bug has been present since v0.58 and should now be corrected.

Further updates will be released once more Oreo-related issues have been identified and fixed :)


Google Play:

Direct Download:

Discussion thread on XDA:

- OTA: Fix new style OTA-download-complete marker detection
- A/B OTA: Add suppport for 'streaming' style OTAs
- A/B OTA: Enable pre-mount by default (required for incremental A/B OTAs now)
- Wipe: Fix dalvik-cache wipe greedily removing some files it shouldn't

Post has attachment
FlashFire v0.71 released

This update is currently rolling out on Google Play.

This update brings some more Oreo related fixes. Some of them related to FlashFire's flash mode startup (fixing some black screens), and some of them related to the OTA handling. Most of the latter are related to Pixel devices, though.

Expect more Orea-related issues to pop up (and be fixed) over the next few weeks :)


Google Play:

Direct Download:

Discussion thread on XDA:

- A/B OTA: Fix update_engine_flashfire crash in logs
- A/B OTA: Always make update_engine_sideload available
- A/B OTA: Fix fstab availability for new style OTAs
- A/B OTA: Don't automatically delete OTAs after successful install if located on internal storage or sdcard
- A/B OTA: Detect target slot rather than blindly switching to the other one
- FlashUI: More Android Oreo compatibility fixes

FlashFire v0.70 released

This update is currently rolling out on Google Play.

The only change in this update is the flash mode UI's compatibility with Android Oreo. The graphics driver used has been updated to cope with the new changes (probably Treble related).

No further extensive compatibility testing has been done yet, but the quick tests I have done seem to work fine.

Aside from that, it has come to my attention that if you're using root with modules, sometimes these modules prevent FlashFire from working. Not sure yet exactly why, but if FlashFire doesn't work for you, try (temporarily) disabling all modules and trying again.


Google Play:

Direct download:

Discussion thread on XDA:

LiveBoot v1.60 released

I've just uploaded v1.60 to the Play store (should start rolling out within a few hours), or you can grab the APK from the XDA thread.

This update brings compatibility with SuperSU's SBIN mode (a tiny but important modification), and updates the graphics code to work with Android 8/Oreo.

The latter took some hair-pulling to get right, but it's here now. The same code is used in FlashFire, so that should soon also see an Oreo-compatible release.


Google Play:


- Add compatibility with Android Oreo
- Add compatibility with SuperSU in SBIN mode
- Fix toolbox/toybox detection on 64-bit, could cause animation to keep running
Wait while more posts are being loaded