January 9, 2013 By: Haroon Q. Raja
Lately, several devices have been getting Jelly Bean in form of CM 10 and CM 10.1 ports. Recently, we brought you unofficial CM10.1 ports for the Nook HD+ and Samsung Galaxy Fit. Now, the Galaxy Player 5 and Strait Talk Galaxy S2 have joined the club, thanks to unofficial ports by XDA Forum Members Mevordel and mr-cook, respectively.
The Straight Talk SGS2 port is based on Android 4.2.1, and should work fine as a daily driver. The developer also provides several other useful goodies in the thread, including ClockworkMod recovery, stock and AOSP modems, and the stock factory image and flashing instructions to get a clean start.
Moving on to the Galaxy Player 5 port, it’s an early release with a lot of work yet to be done to make it suitable enough for daily use. Currently Bluetooth, Camera, and the earpiece aren’t functional. You do, however, get sound through the speaker on the back. The capacitive buttons are also not working on international version, and only earphones with a built-in microphone work. The port is still work in progress, and hopefully these issues will be sorted out soon in a future release.
November 3, 2012 By: Joseph Hindy
When the Meizu MX was first released, many talked about its unique FlymeOS. It’s an OEM skin similar to Samsung’s TouchWiz and HTC’s Sense. It has several fun features and a very nice looking interface. Unfortunately, it was only available on the Meizu MX. It has now been ported to the AT&T Samsung Galaxy S II.
XDA Senior Member estabien has begun porting Flyme OS to the AT&T Galaxy S II. It’s a slow process, as it usually is when porting OEM skinned ROMs. There are a few things working, but many bugs as well. Here’s the list of things working and not working:
What doesn’t work:
Cannot hang up on call (Have to reboot in order to hang up)
Some system settings FC
Doesn’t read SD card
Music Player doesn’t display music
Please report if anything else doesn’t work!
The essentials (data, signal, SMS) do work, but there are a lot of things that still don’t. So this likely won’t be anyone’s daily driver right now. It’ll definitely be fun to test. But for many, it may be best to wait a few more updates for some of the bugs to get squashed.
If this looks like something you’d like to try out, go to the original thread.
October 1, 2012 By: egzthunder1
Quick, simple, and dirty. Some of the best hacks around on XDA require very little to get them to work, and make your life easier in the process. Also, these “simple tricks” tend to fix major snafus from some manufacturers when it comes to so-called features that make you ask “What in the world were they thinking?” So is the case for many Samsung Galaxy devices.
One common complaint is how external storage on Galaxy devices is “weird” (for lack of a better word). Samsung coders decided to treat the internal storage on the device as the external part, which forces several apps to save data, settings, and more to this part of the device. This is impervious to flashing, so it is not that dangerous and your data stored there will survive a flash. However, people seem to like the idea of removing the SD card to use it elsewhere, as well has having the USB storage data for ALL their apps stored within.
With this in mind, XDA Forum Member jocala developed a quick app with a simple GUI that allows the user to switch the destination of the external SD card where it belongs—on the external SD card. The dev has only tested this on the Samsung Galaxy Exhibit, but it should work on other devices so as long as the /system/etc/vold.fstab file matches.
A full Nandroid back up is strongly recommended before attempting this. Please take it for a spin and post your results, including phone model, in the dev’s thread.
A common complaint about some Samsung Gingerbread phones is the fact that they mount the relatively small internal sd memory as /mnt/sdcard and this memory is treated as the phone’s primary removable storage by some apps, ignoring the “real” removable sd card that Samsung refers to as “/mnt/sdcard/external_sd”.
You can find more information in the original thread.
Want something published in the Portal? Contact any News Writer.
By now, you’ve undoubtedly heard about the Samsung HardBrick bug that has reared its ugly head on various Samsung Exynos 4210-based devices including but not limited to the Galaxy Note GT-N7000, Epic 4G Touch, AT&T Galaxy S II, and the Korean SHW-M250S/K/L. In fact, we recently featured an app made by XDA Elite Recognized Developer Chainfire aimed at determining your particular device’s risk for hard brick.
Samsung is aware of the issue, which was first noted by Elite Recognized Developer Entropy512, and is in the final stages of delivering a solution. Until then, however, it is still advised to not flash any leaked kernels, or kernels in which MMC_CAP_ERASE is present.
We’ve contacted Samsung about the problem where performing a mmc erase could hardbrick your phone (i9100, i9100g, n7000, m250 – MAG4FA, VYL00M, and KYL00M with firmware revision 0×19 // T989 and I727 with fw rev 0×12) if it’s having a faulty emmc chip.
Read this thread for more informations about it: http://forum.xda-developers.com/showthread.php?t=1644364
They’re working as hard as possible on a clean solution which will be ready soon.
Please be patient and try to not flash any leaked kernels or kernels based on sources where MMC_CAP_ERASE is present.
In fact, earlier today Samsung contacted me to inform the community that progress has been made. In addition simply releasing a fix in the form of updated stock firmware, Samsung is also working with community developers to provide them the information they need to fix the issue in their own releases. This is important because binaries or patches released to end users require extensive (and time-consuming) testing. This way, however, developers can begin to incorporate the fixes as soon as possible.
We’re thinking two steps to provide.
One is to share the information that open source developers can use to fix the problem.
The second one is the patches applicable for both Official Samsung ROM users and Custom ROM users.
Due to our duties to provide more complete binaries to our customers, our patches require the full testing, which takes longer time.
That’s why we want to share the information first.
Good job, Samsung! It is commendable to see not only your team’s efforts to fix the issue, but also work with the community to ensure that the fix is disseminated as quickly as possible!
[Image taken from egzthunder1's fantastic article on the matter.]
June 6, 2012 By: Will Verduzco
By now, we’re all familiar with the hard brick bug that’s plagued various Samsung when updating to leaked builds of ICS. The bug has shown up on various Samsung Exynos 4210-based devices including the Galaxy Note GT-N7000, Epic 4G Touch, AT&T Galaxy S II, and the Korean SHW-M250S/K/L.
However, as we quickly found out, not all eMMC revisions were equally afflicted. Instead, the 0×19 revision was highlighted as known bad, whereas the 0×25 is thought to be safe. Revisions between 0×19 and 0×25 are thought to be possibly bad, whereas those newer than 0×25 are probably safe. Adding insult to injury, those keen on hex will be quick to notice that 0×19 converted to decimal is 25!
Naturally, someone was bound to create a simpler way of determining the status of your device, and that someone is XDA Elite Recognized Developer Chainfire. With his new app Got Brickbug, users can easily check their device to see their risk status for the hard brick bug. As explained by Chainfire himself:
Attached is a simple APK that reads out your chip’s type and CID, and lets you know if we know that chip is dangerous or safe.
Just uninstall again after using.
Obviously, this comes “as-is”, we’re not responsible what you do with your device, etc. No rights can be derived from the output of the program!
Internal data used:
MAG4FA, VYL00M, or KYL00M fwrev 0×19 –> known bad
MAG4FA, VYL00M, or KYL00M fwrev >= 0×25 –> probably safe
MAG4FA, VYL00M, or KYL00M fwrev != 0×19 && < 0×25 –> probably bad
Everything else: unknown chip
As this is relevant information for any flashaholic, we recommend you head over to the application thread to test your device.
[Image stolen from egzthunder1's fantastic article on the matter.]
May 18, 2012 By: egzthunder1
Since the latest leaks for the Samsung Galaxy S2 line up have been hitting us left and right, people have been jumping between ROMs—mainly between buggy, pre-release ICS builds and very stable GB. This is, after all, what we do on XDA as a habit: We see a leak, we flash it, we use it, and we tweak it. If it doesn’t fly, we simply roll back. Of course, there is always an inherent risk in flashing stuff that should not be on your device in the first place, but the risk of fully bricking a device in this day and age is rather small. Especially, since there are tools available to bring your devices back from the dead, such as UnBrickable Mod by XDA Elite Recognized Developer AdamOutler.
Having said this, not everything seems to be fine in the world of leaks. Thanks to XDA Elite Recognized Developer Entropy512, we have learned that most devices that are receiving leaks are at a very high risk of never waking up after a flash. It turns out that there is a major bug in the leaked ICS kernel that affects the /data partition in the eMMC chip, which apparently gets corrupted during certain operations such as wiping and flashing. This was originally believed to be affecting only operations performed in custom recoveries such as CWM. However, there have been reports of hard bricks being produced from the flashing from stock recoveries as well. The affected devices are:
Entropy and other devs have posted several warnings scattered throughout the site, in which they explain in detail what is happening. Our suggestion is that users should stay away from flashing ICS from leaks until the bug in the kernel has been completely fixed—unless of course, you are looking to hard brick your device. Remember, this is not something that can be resurrected via Unbrickable Mod or even via JTAG, as this is a firmware error in the eMMC. This is directly from Entropy himself for those of you interested in a bit more detail:
DANGER: Many Samsung ICS leak kernels may damage your device!
Those who pay attention to goings-on with various Samsung devices may have noticed that some devices are experiencing a large quantity of hardbricks when ICS leaked kernels are used. These hardbricks are particularly nasty, in that vendors of JTAG services have been unable to resurrect these devices, unlike simple bootloader-corruption hardbricks. This is due to the fact that these kernels are actually managing to cause what appears to be permanent damage to the eMMC storage device.
Kernels that are confirmed affected are:
[*]All Epic 4G Touch (SPH-D710) ICS leaks[*]All Galaxy Note (GT-N7000) ICS leaks[*]The AT&T Galaxy S II (SGH-I777) UCLD3 leak – and probably all others[*]Korean SHW-M250S/K/L official releases and any kernel built from their source
Kernels that SHOULD be safe are:
[*]GT-I9100 ICS leaks[*]GT-I9100 official releases[*]Kernels built off of the GT-I9100 Update4 source base
Operations that are likely to cause damage when running an affected kernel:
Wiping in CWM (and likely any other custom recovery) (confirmed)
Restoring a Nandroid backup in CWM (wipes first)
Flashing another firmware in CWM (most flashes wipe first)
Wiping in stock 3e recovery (suspected, also wipes a partition)
Deleting large files when running an affected kernel (suspected but not confirmed)
If you have an affected kernel:
Flash a known good kernel using Odin/Heimdall immediately. Do NOT use Mobile Odin, CWM, or any on-device method to flash. Known good kernels include:
[*]Nearly any Gingerbread kernel[*]ICS kernels built from the GT-I9100 Update4 source code
The root cause of this issue has yet to be determined, however, numerous Recognized Developers in XDA suspect it is due to Samsung enabling a feature in the affected kernels, MMC_CAP_ERASE – This is a performance feature that can greatly increase flash write performance, but appears to bring out a flaw in the flash chipset. GT-I9100 ICS kernels do not have this feature enabled and appear safe. However, not enough is known to declare all kernels without this feature safe – the only entity that can confirm the root cause of this problem and declare it fixed without taking great risk (destroying multiple devices with no way to repair them) is Samsung themselves.
In general, until further notice, if you are running a Samsung ICS leak for any Exynos-based device other than the GT-I9100, it is strongly advised to flash something else.
And this just showed up this morning in our forums as well, courtesy of XDA member garwynn. Apparently, Google has been contacted and they are aware of the issue, and one engineer is hoping to work towards a fix.
Well, it’s been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)Quote:
Originally Posted by Ken SumrallThe patch includes a line in mmc.c setting fwrev to the rights bits from the cid register. Before this patch, the file /sys/class/block/mmcblk0/device/fwrev was not initialized from the CID for emmc devices rev 4 and greater, and thus showed zero.(On second inquiry)
fwrev is zero until the patch is applied.
Question: Revision didn’t match the fix
(Emphasis mine in red as it discusses the superbrick issue.)Quote:
Originally Posted by Ken SumrallYou probably have the bug, but rev 0×19 was a previous version of the firmware we had in our prototype devices, but we found it had another bug that if you issued an mmc erase command, it could screw up the data structures in the chip and lead to the device locking up until it was powered cycled. We discovered this when many of our developers were doing a fastboot erase userdata while we were developing ICS. So Samsung fixed the problem and moved to firmware revision 0×25.Yes, it is very annoying that 0×19 is decimal 25, and that led to lots of confusion when trying to diagnose emmc firmware issues. I finally learned to _ALWAYS_ refer to emmc version in hexadecimal, and precede the number with 0x just to be unambiguous.However, even though 0×19 probably has the bug that can insert 32 Kbytes of zeros into the flash, you can’t use this patch on devices with firmware revision 0×19. This patch does a very specific hack to two bytes of code in the revision 0×25 firmware, and the patch most likely will not work on 0×19, and will probably cause the chip to malfunction at best, and lose data at worst. There is a reason the selection criteria are so strict for applying this patch to the emmc firmware.I passed on our results a few days later mentioning that the file system didn’t corrupt until the wipe. This is a response to that follow-up.As I mentioned in the previous post, firmware rev 0×19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can’t even start fastboot, the device is probably bricked. If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I’ll ask.
Question: Why the /data partition?Quote:
Originally Posted by Ken Sumrall (Android SE)Because /data is the place the chip that experiences the most write activity. /system is never written to (except during an system update) and /cache is rarely used (mostly to receiving OTAs).
Question: Why JTAG won’t work?Quote:
Originally Posted by Ken SumrallAs I mention above, the revision 0×19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don’t know if I can share it. I’ll ask.
Question: Can a corrupted file system be repaired (on the eMMC)?Quote:
Originally Posted by Ken Sumralle2fsck can repair the filesystem, but often the 32 Kbytes were inserted at the start of a block group, which erased many inodes, and thus running e2fsck would often result in many files getting lost.
So, while the fix doesn’t apply to us at the moment, we’ve been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we’ll see it released!). The bug likely applies to us and assuming the fix for the 0×19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:Quote:
Originally Posted by Ken SumrallYou are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Please stay clear from flashing anything ICS onto your devices until this has been solved.
Want something published in the Portal? Contact any News Writer.
[Thanks Entropy512 for all your hard work!!!!]
As the new versions of Android keep on coming, so do newer versions of OEM software and skins. With HTC’s release of Sense 4.0 and Motorola always tinkering with the Motoblur software, it’s only natural for Samsung to follow up with a newer iteration of what could be their best yet, TouchWiz 4.5.
Most Samsung devices, however, don’t come equipped with 4.5 out of the box, and many users would like to experience it on their own devices. For those running the AT&T Samsung Galaxy S II SGH-I777, you not only have the ability to run TouchWiz 4.5, but now you can run it on a variety of ROMs.
XDA Senior Member crazyagg has been maintaining a thread that features a number of stock apk files from TouchWiz 4.5 builds for users to install and use to experience. While there are a few apk files there to download separately, the full ICS apk zip file has over 60 ICS apks from TouchWiz 4.5, and users can basically pick and choose any or all parts of 4.5 to install.
While the complete package zip is not recovery-flashable, all the pieces are there for those wishing to use them as a base for development or to simply try out 4.5. If 4.5 doesn’t tickle your fancy, crazyagg has also uploaded the stock apks for anyone who needs to revert.
For additional information, the download links, instructions and more, hit up the original thread.
AT&T Samsung Galaxy Note users might want to have a look at this. With all the interesting stuff going on with NFC (Near Field Communication), from using Google Wallet to make real-life purchases with your phone to contact sharing and even initializing multiplayer games, it’d be a shame to have a NFC chip in your device and not be able to use it. Some of the more notable devices that have the NFC chip include the Samsung Galaxy S II, the Motorola Droid RAZR, and the HTC Amaze 4G.
The Korean version of the Galaxy Note has an activated NFC chip. Now, thanks to XDA Forum Member fox689, AT&T Note users can enable the NFC chip on their own devices. From the original thread:
This flash contains an xml permissions file and the Tag.apk from the Canadian ROMs.
Once you’ve flashed this you will have the option to turn on NFC in Wireless Settings as well as be able to install NFC apps from the Play Market.
If you’d like to give it a shot on your Note, check the original thread for download links and install directions. You will have to flash this mod through recovery, so be sure to make a full backup of your device and read all instructions before you jump in.
March 26, 2012 By: Joseph Hindy
Most tools help users and developer add things to their Andorid devices—be it themes, mods, or even GUI interfaces that flash kernels and ROMs. However, there’s another genre of tool that is just as essential to the Android experience: applications that backup essential system files that can easily be broken when flashing development work.
XDA Senior Member HellcatDroid created one such tool for Samsung Galaxy S II, allowing users to perform numerous tasks including backing up and restoring EFS, dumping the kernel, flashing kernels, and verifying that your EFS partition is intact. The tool has been out for awhile, and most of the bugs have been worked out.
One of the major changes in the newer versions is that it now supports all of the US carrier-branded variants of the device, including Sprint’s Epic 4g Touch, the T-Mobile Samsung Galaxy S II and the AT&T Samsung Galaxy S II. This means pretty everyone with a Galaxy S II can partake in .
For additional information, screen shots, a full change log and feature list, check out the utility thread. Now before anything goes awry, backup your EFS partition. If it’s too late for your device, and you have already borked your EFS and IMEI, you’ll need a more manual method.
March 18, 2012 By: Joseph Hindy
There is no such thing as too much security when it comes to mobile devices. There are ways around pretty much every security method out there—from using fingerprints to figure out pattern locks to programmers creating malware that doesn’t fit into anti-virus definitions.
With that said, how many people knew that SMS and MMS messages were stored in logs and could be viewed, even after they’re deleted, by anyone who picks up their phone? It’d be safe to bet not many. And while it’s not a security risk per-say, it’s definitely a chance to invade privacy even when one thought their privacy was being protected. This is a problem that XDA Forum Member jeboo is looking to solve for at least owners of the AT&T Samsung Galaxy S II.
What the modification does exactly is edit the mms.apk to skip the portion of code that puts the MMS or SMS into the log and since they stop being put into the log, people can stop using that method to read your old SMS and MMS messages. In the words of the developer:
Note that with this patch the log entries are never saved. So if someone gets a hold of your phone and tries to dig them up, you’re fine!
The application of the patch requires some apk compiling and de-compiling skills. So if you’re not quite brushed up, it’s recommended that you do so before attempting. And, as usual, don’t forget to make a backup before changing anything, just in case.
For additional information, the full instructions and discussion, check out the original thread and get those text messages gone for good.