Related
Please read Post #2 for background info.
Post #3 discusses safety.
Post #4 lists affected devices and the status of their CyanogenMod ports.
Post #5 details the work needed to support a new device.
This is a work in progress. Please subscribe to this thread to keep up to date. More to follow soon.
Currently Supported Devices
Galaxy S II International (i9100)
Galaxy S II AT&T (i777)
Galaxy S II Epic 4G Touch (d710)
Galaxy Galaxy Note (n7000)
In Short
Brickbug fix by independent developers killed TRIM. Because of this, all devices -affected or not- running 'safe' custom roms end up slowing to a crawl with enough usage.
Samsung's later fix does not inhibit TRIM, but it is widely believed that their fix is incomplete and inadequate. I beg to differ and believe Sammy's fix could well be adequate, and I have good reasons for it. They are summarized in Post #3.
Which Devices Are Known To Be Affected?
Please refer to Post #4.
What To Do?
Make CyanogenMod builds for affected models where the indie fix is replaced with sammy's fix.
CLEARLY LABEL THEM AS DANGEROUS.
Is That Enough?
No, you need to actually invoke fstrim somehow. Android 4.3 and later automatically does so daily when left overnight to charge. You can invoke fstrim manually from a root shell, or just use this app instead. Also, there are scripts you can flash to fstrim on boot.
Are The Builds Safe?
It depends. Not all devices of a particular model known to be affected by brickbug carry the bug. If your device is brickbug-free, then yes, it is safe. You have been running crippled custom roms for ages now and you definitely want these builds to restore the speed and responsiveness of your device.
If your device is affected by brickbug, then it could be safe or not. I suspect yes, but testing is needed. Please refer to Post #3. You are strongly advised NOT TO TRY THESE BUILDS or else your phone could very well die forever. You have been warned.
How Do I Know If My Device Is Affected?
Use this app. Root is requested but not needed for this test. WARNING: Do not trust its verdict! Instead use the reported eMMC model name and the firmware revision (fwrev) to look up your eMMC in this table. Of particular concern is the TRIM bug supposedly present only in MAG2GA eMMCs.
How Do We Test Safety?
I hope some volunteer with an affected device and a partially cracked screen may show up. Also, I have a working Galaxy S2 i9100 display (dead mobo); if someone has an affected fully cracked S2 to donate, that could work. I live in Argentina, but I have friends in the US that come and go.
How Do We Test Performance?
Use Androbench. Make sure you have plenty of free space in your internal memory. Run it on your standard CM before switching to trim-enabled CM. Take a screenshot? Switch, trim the file systems, and rerun.
My Device Is Affected. My Device Is Too Slow. Is There An Alternative For Me To Restore Performance Now? I Do Not Want To Wait For This Project
Yes there is. But involves trade-offs. I will write about it soon.
XDA:DevDB Information
BrickbugAftermath, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Version Information
Status: Beta
Created 2014-07-21
Last Updated 2014-09-13
The Background
During the early crazy days of the brickbug saga, developers such as Entropy512 struggled to understand what was happening and how to put an end to the long line of dead devices that modders were rapidly accruing. All the while Samsung helped with their usual routine, a mixture of silence, denial and deception.
Developers found the problem: certain perfectly legal commands when sent the the eMMC (the solid state drive inside phones) destroyed the eMMC module. The module made by Samsung includes flash memory, a processor and its software (called firmware). The firmware implements an FTL, a flash translation layer, that emulates something akin to a harddrive atop the flash memory. This firmware had a bug that caused corruption on its own data structures when certain commands were executed. When the processor later accessed these corrupt structures (say, to read the bootloader partition on power on) it stopped responding, and as a result the devices never booted again.
<RANT>This buggy firmware is Samsung's trade secret and opaque to independent developers, and developers could not change it. Samsung had tools to upgrade the firmware and eliminate the bug (we know this because Google engineers were given this tool) but chose not to release it. In all probability Samsung could also reset the dead eMMCs with software, but preferred to screw their customers. I imagine Samsung failed to care about field upgrades and did not include a firmware update route in the module that supported encrypted firmware images. Then releasing a firmware upgrade tool to fix their buggy module would expose their precious secret silly little buggy firmware without encryption. And it seems they rather just screw their customers instead.</RANT>
Developers worked around the bug by making sure a whole class of eMMC commands would never be issued and urged everybody to upgrade their 'dangerous' (standard actually) custom roms to 'safe' (read 'crippled') alternatives.
Samsung later released 'safe' Android updates. But their version of 'safe' only excluded a subset of the of commands excluded by independent developers. The general response of developers was distrust of Samsung and the belief that Samsung's fix was not enough and not 'safe'. This based mostly on a very bad track record by Samsung during the brickbug days, involving technical matters, denials and lies.
TRIM
Flash storage in general (including the eMMC) requires that certain commands be ran regularly in order to keep performance high. If not, under normal usage performance will degrade enormously. (This is a result of so called write amplification and other effects.) As users can vouch, devices like the Galaxy S2, the Galaxy Nexus, and the Nexus 7 were snappy and fast when new; then they gradually became abysmally slow after months of use.
These commands are called DISCARD, ERASE, TRIM or fstrim depending on context and software stack level, but mostly refer to the same core function.
The Brickbug Aftermath
And this is the problem: the brickbug fix that independent developers implemented disable these commands. This means that running a custom rom in the affected devices pretty much guarantees that you will end up with a ridiculously sluggish device given enough time. In effect, these devices severely under-perform when running custom roms due to software issues that can possibly be fixed. With the current state of affairs, I would go as far as considering custom roms useless for these devices.
This project aims to provide a safe TRIM solution for these devices when running custom roms.
This project has to be executed carefully. I expect accusations of recklessness to be thrown at me for reintroducing 'unsafe' roms. And maybe a couple of devices of careless people will die.
But many other devices will find new life and become usable again.
Is It Safe To TRIM A Device Affected By Brickbug?
Maybe. Folklore says no, but there are good reasons to believe it is safe. Testing, possibly destructive, is required.
Indie developers' fix disables all trim and erase commands sent to the eMMC. Samsung's fix converts secure erase and trim requests to their non-secure counterparts and dispatch them. (Trim and erase are essentially the same function using different arguments.) The non-secure versions are what we need for performance. The secure versions are needed for privacy, to actually assure data is deleted from the eMMC, for instance when wiping a phone clean before selling it. (Note that the non-secure commands will typically wipe beyond recovery unless you are the NSA or something like that: the data becomes inaccessible and you would need to side step the FTL controller and access the flash directly to get to it, which requires physically dissecting the module or else hacking the FTL firmware.)
People I have talked to simply doubt that Samsung's fix is enough, maybe for no good reason. Although I am very critical of Samsung on many fronts as other posts in this thread clearly show (to the point of promoting a total boycott of the brand), I will play the devil's advocate in this case and try to convince you that maybe Samsung got it right this time.
There is no question that secure erase and trim trigger the bug and brick the eMMC and thus the device. The question is whether non-secure erase and trim are safe or not. Folklore says no, you be the judge:
Reasons to believe non-secure erase and trim are unsafe:
Samsung showed ineptitude during this whole mess and cannot be trusted.
Secure and non-secure erase and trim commands have frighteningly similar names.
Reasons to believe non-secure erase and trim are safe:
I could not find a single documented case of bricking due to an non-secure command anywhere on the net. I have also talked to Entropy512 the brickbug hero and to the author of the LagFix app and they could not single out any such event.
Samsung investigated the bug in their secret firmware and definitely found it because they fixed it in later versions. Knowing exactly what was wrong with the firmware, and having been shown how indie developers fixed the bug, Samsung decided to implement a different fix that instead converted secure commands to non-secure, presumably because they know that non-secure commands are safe. (But some think it could just be humongous ineptitude.)
They had enough confidence in their fix to push it upstream with enough dedication as to apparently have it mainlined. I am not an expert on linux kernel politics, but this fix apparently made it all the way up into none other than Linus Torvalds git tree. I think this means that all linux kernels everywhere, from desktops to supercomputers, will now have this silly brickbug patch in their kernels. I can only imagine adequate effort has been expended in verifying its effectiveness.
Typically Samsung's stock 4.1.2 androids include the patch (Galaxy S2 I9100 4.1.2 has it for sure), and I could not find accounts of brickings using Sammy's patched stock androids anywhere on the net.
Finally, and more convincingly to me, despite their similar names, secure and non-secure commands are completely different beasts. Six months ago i discussed how a very naive FTL could be implemented in this post with the intention of showing precisely that. If you care to to read the post you will notice that:
Implementations of secure and non-secure erase are extremely different.
The implementation of secure erase is vastly more complicated.
The implementation of non-secure erase is actually a subset of the implementation of write. Thus, if write does not trigger brickbug, so should not non-secure erase.
TODO: Investigate this: CyanogenMod's brickbug page maintainer seems to imply that running LagFix (which trims) while using a patched rom is safe. But is he referring to Samsung's or devs' patch? It should be Samsung's, because if it is devs' then LagFix would not work.
WARNING: There is a different bricking bug called TRIM bug that affects TRIM on a specific eMMC. Apparently it has only been observed on the Nook HD+. (But how can we be sure that it is not in other eMMCs (including brickbug-free eMMCs) if TRIM in these modules has never been massively put to use and tried?) The kernel patch mentioned seems to add support for the eMMC DISCARD command on Samsung moviNAND 4.41+ eMMCs and then choose it over TRIM while doing file system trimming. It is not apparent anywhere that this is a workaround for a bug, but by preferring DISCARD over TRIM it may sidestep a TRIM issue. DISCARD is a new command only featured in newer eMMCs. It is similar to TRIM but enables faster implementations. The patch is Samsung-specific but not specific to any eMMC device. It could be ported to any kernel but wont help unless the eMMC is moviNAND 4.41+. Note that older Samsung eMMCs could be affected by the TRIM bug, although I could not find any information online to support this hypothesis.
Affected Devices
See here for more information.
Which Devices Are Known To Be Affected By Brickbug?
GT-N7000 Galaxy Note (International)
GT-I9100 Galaxy S II (International)
SGH-I777 AT&T Galaxy S II Attain (3G)
SGH-I727 AT&T Galaxy S II Skyrocket (4G)
SGH-T989 T-Mobile Galaxy S II Hercules
Most other Samsung tablets and handsets released in 2011
Amazon Kindle Fire first generation (approximately 50% of units; the rest have unaffected Toshiba eMMCs)
Acer A500 (no official CyanogenMod support)
Nook Color
Which CyanogenMod ROMs Are Known To Include Indie Developers' TRIM-Crippling Brickbug Fix?
Part 1: Recoveries that suppress wiping of eMMC partitions (BOARD_SUPPRESS_EMMC_WIPE)
BOARD_SUPPRESS_EMMC_WIPE
galaxys2-common/BoardCommonConfig.mk
celox-common/BoardConfigCommon.mk
motorola/qcom-common/BoardConfigCommon.mk
(FYI: Recoveries that wipe eMMC partitions non-securely.)
Devices:
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: yes
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: yes
GT-I9100G Galaxy S II (G): no
GT-I9250 Galaxy Nexus (GSM): no
Nexus 7 (2012): no
Amazon Kindle Fire first generation: no
Nook Color: no
Nook HD+: no
Part 2: Kernels that suppress ERASE/TRIM/DISCARD eMMC commands (no MMC_CAP_ERASE)
Each SoC (system-on-chip) has its own set of on-chip peripherals that require specific ad-hoc drivers. Which of these drivers controls the peripheral that is connected to the eMMC is SoC- and board-specific. The indie developers' fix for brickbug entails hacking this driver to make in unable to issue ERASE/TRIM/DISCARD commands by way of removing the MMC_CAP_ERASE capability. I could not find a generic way to know which driver controls the eMMC from sources, so this has to be studied for each case.
XDA's codeworkx (thanks!) provided this info:
Exynos: drivers/mmc/host/mshci.c
OMAP: drivers/mmc/host/omap_hsmmc.c
Kernels and boards:
android_kernel_samsung_smdk4210 (Exynos): yes, but this kernel was abandoned after CM 10.1.
android_kernel_samsung_smdk4412 (Exynos): yes, but only for Mach U1 boards (including i9100 and i777).
android_kernel_samsung_msm8660-common (Snapdragon S3): boards seem to use SDCC1 for the eMMC, including celox, so apparently not.
Devices:
GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G): yes, these are Mach U1 boards.
GT-N7000 Galaxy Note (International) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: maybe; are these Mach U1s?
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: these are celox, so APPARENTLY NOT !!!
GT-I9100G Galaxy S II (G): unknown
Galaxy Nexus (GSM / Sprint / Verizon): unknown
Nexus 7 2012 (WiFi / GSM): no (tested fstrim)
Amazon Kindle Fire first generation: unknown
Nook Color: unknown
Nook HD+ : unknown
Which CyanogenMod ROMs Are Known To Include Samsung's Brickbug Fix?
Fixed kernels:
first implemented fix (MMC_QUIRK_MOVINAND_SECURE)
mainline fix (MMC_QUIRK_SEC_ERASE_TRIM_BROKEN)
Devices:
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: yes (for CM 10.1 and earlier: yes)
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: yes
GT-I9100G Galaxy S II (G): yes
Galaxy Nexus (GSM / Sprint / Verizon): no
Nexus 7 2012 (WiFi / GSM): no
Amazon Kindle Fire first generation: NO !!!
Nook Color: NO !!!
Nook HD+ : no
Which Devices Are Known To Be Affected By WL Bug?
Galaxy Nexus
Which CyanogenMod ROMs Are Known To Include The Fix For WL Bug?
It seems that only 3 kernels include this fix, the Galaxy Nexus, the Nexus Q, and the Qualcomm-based Galaxy S2s.
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: NO !!!
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: yes
GT-I9100G Galaxy S II (G): NO !!!
Galaxy Nexus (GSM / Sprint / Verizon): yes
Nexus 7 2012 (WiFi / GSM): no
Amazon Kindle Fire first generation: no
Nook Color: no
Nook HD+ : no
Which Devices Are Known To Be Affected By TRIM Bug?
Nexus 7 2012
Nook HD+
Which CyanogenMod ROMs Are Known To Include The Fix For TRIM Bug?
These 4 kernels plus these 3 kernels:
android_kernel_samsung_smdk4210
android_kernel_samsung_smdk4412
android_kernel_samsung_jf
android_kernel_samsung_msm8930-common
android_kernel_bn_omap
android_kernel_asus_grouper
android_kernel_htc_msm8960
And I have found these 3 kernels that seem to include the same fix but triggered for specifically singled out eMMC parts. This may be a subset of the 'standard' fix (it may be an older implementation) or may cover devices not covered by the standard implementation. Besides this, nothing else seems interesting.
Devices:
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: yes
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: NO !!!
GT-I9100G Galaxy S II (G): seems to be covered by this eMMC-specific patch
Galaxy Nexus (GSM / Sprint / Verizon): NO !!!
Nexus 7 2012 (WiFi / GSM): yes
Amazon Kindle Fire first generation: no
Nook Color: no
Nook HD+ : yes
Which Devices Are Known To Be Affected By P17 Bug?
Nook Color
Which CyanogenMod ROMs Are Known To Include The Fix For P17 Bug?
It seems that not a single CM ROM includes this fix.
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: no
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: no
GT-I9100G Galaxy S II (G): no
Galaxy Nexus (GSM / Sprint / Verizon): no
Nexus 7 2012 (WiFi / GSM): no
Amazon Kindle Fire first generation: no
Nook Color: NO !!!
Nook HD+ : no
How To Add Support For Device
Please refer to Post #4 for more info.
Make sure Samsung fixes are applied to the kernel.
Make absolutely sure Samsung's Brickbug fix is applied or apply it yourself.
Make absolutely sure Samsung's TRIM bug fix is applied or apply it yourself.
Optionally apply Samsung's WL bug fix.
NOTE: My Exynos 4210 kernels do not have a fix for WL because Entropy512 has told me that no 4210 devices exist that are affected with this bug. But I did prepare a patch for it for CM and it is included in the sources of my 4210 TRIM kernels (though not applied). In any case, this bug involves data corruption, not bricking. Entropy512 also said this bug was never observed, but data corruption happened to me several times on one of the Galaxy Nexus I had, and I suspect this bug was the culprit.
Remove indie developers' fixes.
Please tag all changes with BrickbugAftermath in a comment so that they can be easily found and verified if needed.
Enable non-secure wiping of eMMC partitions in recovery.
This can me done by appending these lines to the BoardConfig.mk device file:
# BrickbugAftermath: Enable non-secure wiping of eMMC partitions in recovery
BOARD_SUPPRESS_EMMC_WIPE := false
COMMON_GLOBAL_CFLAGS += -DNO_SECURE_DISCARD(Make sure the NO_SECURE_DISCARD flag is not already added elsewhere in the makefile or its includes.)
Even when using non-secure discard, partition wiping can be unsafe in the following scenario:
-a complete rom is built with partition wiping enabled
-the full rom is installed on a device
-a different kernel is later installed or booted up
-the kernel is MMC_CAP_ERASE enabled (can trim)
-the kernel does not include the MAG2GA TRIM bug patch
-the device is affected by MAG2GA TRIM bug
Revert suppression of ERASE/TRIM/DISCARD eMMC commands in the kernel.
Find out which kernel driver talks to the eMMC and restore its MMC_CAP_ERASE capability.
For example, in the Exynos 4412 kernel you should effectively revert this change.
Build your ROM and give it a really scary name.
Please name your ROM file like this:
this-will-hard-brick-your-device--cm-11-2014XXXX-XXXXX-TRIM-i9100.zip
People flash before reading and a lot of testing is needed before the general safety of these builds can be assumed.
(reserved 1)
(reserved 2)
Fixing the Celox devices
revert suppression of eMMC partition wipes.
affected devices:
* SGH-I727 AT&T Galaxy S II Skyrocket (4G)
* SGH-T989 T-Mobile Galaxy S II Hercules
* SGH-I577 AT&T Exhilarate
https://github.com/search?q="celox-common+BoardConfigCommon.mk"+user:CyanogenMod&type=Code
the kernel on these devices do not suppress ERASE/TRIM/DISCARD
eMMC commands (ie, they support MMC_CAP_ERASE) so fstrim works.
this is safe because the kernel has samsung's brickbug fix applied.
given that ERASE/TRIM commands are already being used with
each nightly automatic fstrim since android 4.3 and proven safe,
there is no need to keep the partition wiping disabled in recovery.
this line:
BOARD_SUPPRESS_EMMC_WIPE := true
should be remove from:
https://github.com/CyanogenMod/android_device_samsung_celox-common/blob/cm-11.0/BoardConfigCommon.mk
in both cm-11.0 and cm-10.2.
these devices have the following Samsung fixes applied:
* brickbug: YES, since CM 10.2
https://github.com/CyanogenMod/andr...mmit/2fdc4e253df2af8490c389a0840febbdec5f5175
* wear leveling data corruption bug: YES, since CM 10.2
https://github.com/CyanogenMod/andr...mmit/16636bd32b80f9d77d5e4e36f30498292810d61b
* MAG2GA TRIM bug: NO
* M8G2FA "P17 corruption" bug: NO
more information:
http://forum.xda-developers.com/showpost.php?p=54295205&postcount=4
Hi Guys, I'm wondering if Mi4 is still worth it to get today. I have the chance on also getting the Mi4C instead. So I would like to know your experience with it and if you have had the chance to try and compare it to the Mi4C, what would you recommend me to go for.
Mi4 or Mi4C
I wonder if is it a deal breaker to get the Mi4c over the Mi4, taking in count both cameras and the processor. Considering also both with 3 gb ram, and software development such as custom roms and xiaomi official firmware.
Thanks
amiguielesl said:
Hi Guys, I'm wondering if Mi4 is still worth it to get today. I have the chance on also getting the Mi4C instead. So I would like to know your experience with it and if you have had the chance to try and compare it to the Mi4C, what would you recommend me to go for.
Mi4 or Mi4C
I wonder if is it a deal breaker to get the Mi4c over the Mi4, taking in count both cameras and the processor. Considering also both with 3 gb ram, and software development such as custom roms and xiaomi official firmware.
Thanks
Click to expand...
Click to collapse
I did get the mi4 because:
- Better design (in my opinion)
- possibility to install w10
- more roms ( i think)
and in terms of performance and camera they are almost equal.
Mi4 should have better camera, F1.8 aperture size.
I am going to buy a new smartphone and the 2 alternatives are Mi4 3gb no LTE (my operator uses mainly 800mhz lte) and Redmi Note 3 Pro 3gb. Prices are $160 for Mi4 and $216 for Redmi. I don´t like phablet but the newer hardware of Redmi Note 3 Pro is also interesting... Any advice?
I'm not a pro, so my advice may be wrong, but I believe the Mi4 kernal is open so you can will get more longer term custom ROM support (eg Cyanogenmod) where as the Redmi might have better specs, but the kernel source may never be released and therefor you'll be restricted to whatever version of MIUI Xiaomi choose to releases on the device. I was faced with exactly the same choice and went with the Mi4. Infact I am about to install CM13 on it.
rimpy said:
I'm not a pro, so my advice may be wrong, but I believe the Mi4 kernal is open so you can will get more longer term custom ROM support (eg Cyanogenmod) where as the Redmi might have better specs, but the kernel source may never be released and therefor you'll be restricted to whatever version of MIUI Xiaomi choose to releases on the device. I was faced with exactly the same choice and went with the Mi4. Infact I am about to install CM13 on it.
Click to expand...
Click to collapse
Thanks but Xiaomi has already released the kernel source for Redmi Note 3 Pro
http://forum.xda-developers.com/redmi-note-3/how-to/kernel-source-redmi-note-3-pro-t3349609
mdki1996 said:
Thanks but Xiaomi has already released the kernel source for Redmi Note 3 Pro
http://forum.xda-developers.com/redmi-note-3/how-to/kernel-source-redmi-note-3-pro-t3349609
Click to expand...
Click to collapse
Ah, I was actually thinking of the Redmi Note 2 which hasn't got a kernel release if I'm not mistaken. I would go for the Note 3 in your case. Better specs, and bigger screen is a good thing too.
Not to bump a thread a few days old, but I'd say the Mi 4. I just bought one on sale for $145 or so with shipping. I was torn as well but the hardware is what appeals to me the most. I also like how you can install Windows Phone 10 on it, I might do that for a few days just to reminisce of my WP days.
I'm currently on a Virgin Mobile USA plan. I have a LG Stylo 2 which I found about after a year that it's impossible to root. I'm planning to get a J7 simply because it seems to be more powerful.
What variants are available, also how difficult is it to root. I've rooted several phones before (HTC, LG).
Thanks
So far it has been really simple. It all depends on your prior knowledge and the availability of techniques. Right now I can go from stock to root, Xposed and a permissive kernel about 20 mins.
xhan145 said:
So far it has been really simple. It all depends on your prior knowledge and the availability of techniques. Right now I can go from stock to root, Xposed and a permissive kernel about 20 mins.
Click to expand...
Click to collapse
For the VM Variant. Not sure if you are using VM. I'm in the US. Is there any issues with adaptable storage, 7.0 (Nougat ), sharing wifi. Biggest thing for me is using a 256GB class 10 micro SD mem card to expand the storage.....
I've been using my OP3 since launch, now I have a Note 8 around here somewhere and I'm thinking to myself: Is it worth to leave Dash Charging, insane fast Fingerprint, Screen-off gestures and AOSP experience for a Note 8. No way around it, I'm going to root the Note 8 100% but the last time I rooted a Samsung was back in 2013, I don't know what has changed.
My main question is, is it worth leaving screen-off gestures, pure Android experience and dash charging to own a pen, bigger immersive screen and Samsung's multi-window app features and other nice things. I really don't care about the camera and both devices are snappy but obviously Note 8 is snappier because I'm not running OxygenOS in OP3 and it is a bit full. I'm running out of storage so that's another reason to switch devices.
What do you say? Which road should I go through? I'm sure I'll be happy with both as long as I'm rooted and running my sweet full pitch black substratum theme. And Magisk of course!
Another little question, as you know there are specific versions of themes that should be installed to work with customized roms. What I want to know is, can I just go ahead and install a WhatsApp overlay that is stated as AOSP to a Samsung device? Will I be fine as long as Android System and SystemUI overlays aren't installed from an AOSP substratum overlay pack?
charackthe said:
I've been using my OP3 since launch, now I have a Note 8 around here somewhere and I'm thinking to myself: Is it worth to leave Dash Charging, insane fast Fingerprint, Screen-off gestures and AOSP experience for a Note 8.....
Click to expand...
Click to collapse
I don't have this device but, the following area of the forum is specific to your device.
https://forum.xda-developers.com/galaxy-note-8
With that stated...
You should be able to obtain some member guidance within one of the following threads that's specific to your device as well.
https://forum.xda-developers.com/showthread.php?t=3685884
https://forum.xda-developers.com/showthread.php?t=3677038
https://forum.xda-developers.com/showthread.php?t=3776628
Good Luck!
~~~~~~~~~~~~~~~
I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
Hi, I like the phone but also I want to put some tweaks like 90hz display, custom roms, pixel 6 camera features(motion mode), kernels...
will we see a lot of development as in the xiaomi poco f1 or not?
thank you
If you have a Xaomi, i recommend keeping it a little longer. Roms for this devive are in a weird situation because the only 2 stable ones are calyx and graphene which arevboth great, but they are both very barebones and kind of difficult if you aren't experienced with degoogling
Twilightsparklez said:
If you have a Xaomi, i recommend keeping it a little longer. Roms for this devive are in a weird situation because the only 2 stable ones are calyx and graphene which arevboth great, but they are both very barebones and kind of difficult if you aren't experienced with degoogling
Click to expand...
Click to collapse
thank you, but with the same cpu as pixel 6 and 6 pro, it will be easy to port roms from pixel 6?
charly30 said:
thank you, but with the same cpu as pixel 6 and 6 pro, it will be easy to port roms from pixel 6?
Click to expand...
Click to collapse
Yes, adding Bluejay is possible. Whether developers choose to do it is another question.
Velocity will be ready for public release soon. I'm just buttoning up a few more things.
I noticed with the phones I've own, custom ROM seem to get me frequent as the phone gets older and the stock rom releases begin to vaporize. If the phone has enuff hardware power n memory AND there's no more factory support (as in many older midrange Motos). The Moto G5+ and G5S+ had active 'post' communities as did the G6...I got a G7 cuz of 4gb memory figured it'd be a big post EOL project/rom phone BUT I missed the fact that moto was following google with the whole dynamic update w/ dual A/B slots which killed our beloved TWRP custom recovery and nandrive image backup.
BUT is u weren't into rooting/tweaking then that explains why Android Police named it the #1 phone for running LOS! Esp. after Moto released thr Android 10 kernel source code!! This is the main reason I didn't sell/trade it off...and ofc my wife put one of those sky-blue 2pc cases from Poetic and claimed it! lol