• 5,806,660
    REGISTERED
  • 50,720
    ONLINE NOW

Posts Tagged: chainfire

Triangle Away

Unless you have been living under a rock, you know what Triangle Away is. If you don’t, Triangle Away is a way to reset the flash counter on Samsung devices. That’s right. In their infinite wisdom, Samsung decided to keep track of the number of times you flash custom firmware to your device. Obstinately, this is to allow them to deny warranties and blame the hardware issues on unauthorized firmware. The logic seems flawed with the solid firmware available on XDA.

Recently XDA Elite Recognized Developer Chainfire released an update to his Triangle Away application, ticking the version number to v2.05. This latest update adds support for the Samsung Galaxy S3 LTE GT-I9305 and the Samsung Galaxy Note 2 LTE GT-N7100. Chainfire says that this update should work on various Qualcomm-based Samsung devices. Chainfire could use your help to determine which of the Qualcomm-based Samsung devices this works on that haven’t been identified.

On October 9th the new 5.5 inch screen wielding Samsung Galaxy Note 2 GT-N7100 was added to the supported devices list. Since our last Triangle Away article support has also been added for the Samsung Galaxy S3 SHV-E210K, Samsung Galaxy S3 SHV-E210S, Samsung Galaxy Note GT-N8000 10.1″ 3G and Samsung Galaxy Note GT-N801x 10.1″ Wi-Fi.

Check out the application thread for more information and to help Chainfire find out what devices this latest update works on.

PerfMon

In the course of developing an application, or even looking at deploying a new kernel or ROM, it is often necessary to benchmark your changes and see what effect your efforts yield. No one should deploy something that gives your users a negative experience. XDA Elite Recognized Developer and Senior Moderator Chainfire feels the same way, so has added a new application to his repertoire: PerfMon.

PerfMon is a “floating” performance tool, which operates as an overlay to your existing application. It will provide real-time stats for the foreground app, CPU, disk I/O and network I/O. These can be used to see exactly how your application performs in any given situation. It also has a new performance metric unique to PerfMon called CPU Capacity Usage. As described by Chainfire:

The CPU usage percentage traditionally used to measure and compare how much of the computational resources an app (or the entire device) is currently using does not make sense in a mobile multi-core setting. The capacity metric will take the CPU usage and scale it to what it would be if all cores were running at full capacity.

For example: if you have a 1.6ghz quad-core running a light app, it could be using 10% CPU with only one of the four cores active, and that core running at 200mhz. If you translate that to all four cores running at 1.6ghz, that app is using only 0.3% of total CPU capacity.

It’s the only CPU Usage metric that makes any sense!

Chainfire has posted the full version in the application thread, where you can find out more about how this works. He also has a link to the Google Play version, so head over there and provide feedback and support his efforts. And if you haven’t already heard, Chainfire will be at the BigAndroidBBQ so if you want to meet the iconic man, and experience what Willverduzco did, make sure you stop by XDA’s booth and say hello.

 

Advertisment
AAPT

There are many of elements that go into compiling any source code. Not only are there various files that need to be compiled, but multiple processes are used to compile them. Sometimes, those processes aren’t always as fast or optimized as they could be. One such example is is AAPT—which stands for Android Asset Packaging Tool. It’s commonly used in compiling Android applications.

While compiling some applications like DSLR Controller, XDA Elite Recognized Developer and Senior Moderator Chainfire noticed that compile times were higher than they ought to be. This warranted an investigation. Chainfire concludes his investigation as such:

So I set out to fix this. I had done all the usual tricks, even gave Eclipse loads more memory (helped with regular performance, but not building) but nothing major seemed to change. Then I figured out most of the time building was spent in AAPT

Based on this find, Chainfire was able to develop a hack that help correct the issues behind the slow build times. Chainfire provided a first build of this hack/fix along with instructions on how to determine if you have the problem that this hack/fix rectifies:

A quick way to spot if this will have effect on your slow build is as follows:

– In Eclipse, set Build output to Verbose under Window -> Preferences -> Android -> Build.
– Clean and build your project.
– If the build pauses on lines in the “(new resource id from )” format, you have the problem FAAPT fixes

As per the norm with Chainfire applications, user response has been quite positive. Nearly everyone who has used this to fix slow build times has seen a decrease in build times to some extent. How much this helps will of course depend on what you’re building and what OS you’re using. Currently, there’s a version for Windows and a version for Linux. It is important to note that Chainfire warns that this is a first release, and to not test it on production builds.

If you’d like to learn more about the fix or take it for a spin, check out the original thread.

triangle_away

That last thing you want to hear when submitting your device for a warranty repair is, “You rooted your device and broke the warranty so I can’t help you. Enjoy your bricked device!” The tech in the store or at the repair center rarely knows exactly what was done, but they tend to pay attention to the status of your bootloader and if you have a rooted device and/or custom firmware. In the case of newer Samsung devices, after flashing a custom kernel, the screen displays a nice yellow triangle on boot signifying you’ve done something that the manufacturer didn’t want you to.

XDA Elite Recognized Developer Chainfire recently created an app called Triangle Away, which clears the system flag on select Samsung devices so that the annoying triangle goes away. Today, he updated the app to version 1.80, which adds support for the US Cellular Samsung Galaxy S III, along with the entire Samsung Galaxy Tab 2 series. Recently added devices:

Samsung Galaxy S2 GT-I9100 **
Samsung Galaxy Note GT-N7000 **
Samsung Galaxy Note GT-I9220 **
Samsung Galaxy S3 GT-I9300 **
Samsung Galaxy S3 GT-I9300T **
Samsung Galaxy S3 AT&T
Samsung Galaxy S3 Sprint
Samsung Galaxy S3 T-Mobile
Samsung Galaxy S3 Verizon
Samsung Galaxy S3 Canadia
Samsung Galaxy S3 US Cellular
Samsung Galaxy Tab 2 GT-P310x 7″ 3G
Samsung Galaxy Tab 2 GT-P311x 7″ Wi-Fi
Samsung Galaxy Tab 2 GT-P510x 10″ 3G
Samsung Galaxy Tab 2 GT-P511x 10″ Wi-Fi

** Various related models are supported depending on firmware, but only the exact model numbers listed are supported regardless of firmware version.

Head on over to the original thread to get more information and to download the application.

Tk2

Here at XDA Developers, we love to flash our devices to our hearts content. However, Samsung has introduced a kernel flash counter that keeps track of custom kernel flashes. XDA Elite Recognized Developer Chainfire then created an app to reset the counter and make the triangle go away. Chainfire has adapted that to many devices.

In this video our buddy TK reviews the application. He reviews what features he likes and talks about the application. He discusses Chainfire’s back and forth with Samsung. They try and work around his application, and Chainfire figures out how to make TriangleAway.

 

 

READ ON »

sammybrick

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-N7000Epic 4G TouchAT&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.

As seen on a Google+ post by XDA Elite Recognized Developer codeworkx:

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 0x19 // T989 and I727 with fw rev 0x12) 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!

Those looking to learn more should head to the discussion thread started by XDA Forum Member androidindian.

[Image taken from egzthunder1's fantastic article on the matter.]

The Chainfire Block

Expert news summarizer Jordan returns for today’s episode of This Week in Development. Jordan talks about Microsoft’s on{X} Quick Look and Tutorial. Jordan mentions another XDA Portal news article about a beginner’s app creation tutorialHola Mundo!

Jordan then covers the deluge of XDA Elite Recognized Developer Chainfire’s latest developments, from CF-Root being Released for the International Samsung Galaxy S III I9300, to Possibly the Final Release of TriangleAway for the Samsung Galaxy S III and International Note, to Mobile ODIN Updated for the Samsung Galaxy S III I9300. Jordan talks about the developments for the Xperia Pro, Arc, Arc S, Sola, U and P.  Lastly Jordan reminds you of his Linux tutorial from earlier this week

READ ON »

adbd insecure

We are all undoubtedly aware of adb. In fact, most of us use it quite often in order to execute commands on our mobile devices from the comfort of our computers. It allows you to do this such as push and pull files on the device, retrieve logcats to send to your favorite dev when your kernel causes a bootloop, reboot to recovery or bootloader, and many other useful things. It is also the core of most one-click root methods. Ultimately, it is the adbd (ADB Daemon) that is responsible for allowing you to access the shell and all the other cool functions. For most stock kernels, however, it seems that this only allows you to run adb in secure mode even if you have a rooted device.

So, if you have a stock kernel and want to have all the goods that comes with an insecure adbd (write access to /system goodness and much more), you may want to take a long look at a new release by XDA Elite Recognized Developer Chainfire. He has released an APK that allows your device to run adbd in insecure mode, even if you are rooted and on stock kernel. The app doesn’t enable insecure adbd permanently, and will thus revert to the standard adbd upon reboot. However, there is an option to restart insecure adbd on boot.

There is a good chance that if you are running a custom kernel, you do not need this app. Chainfire mentions that this app must be installed on rooted devices, and that it may not work if your device has a locked bootloader. Please take it for a spin and leave some feedback for the developer.

You can find the free application in the original thread. Alternatively, you can purchase a donate version in Google Play.

Want something published in the Portal? Contact any News Writer.

[Thanks Chainfire for the tip]

unnamed1

Back in November of last year, we took a quick look at Mobile ODIN by XDA Elite Recognized Developer Chainfire. Later in February of this year, the app was updated to version 2.0, which added an impressive number of supported devices. Now, the app has been updated once more to support even more devices, including the device that is seemingly on everybody’s mind—the Samsung Galaxy S III GT-I9300.

For the uninitiated, Mobile ODIN does as its name implies and serves as an on-device ODIN utility. It allows users to fully flash their firmware straight from the device itself—practically removing the need to connect your device to a host computer. Due to safety reasons, however, the EFS and bootloader partitions are not flashed. Just as before, two versions are available: a lite version that is available exclusively on XDA, and a pro version that can be found on the Android Market.

In the words of the developer:

New in v2.10:
– Samsung Galaxy Tab 7.0 Plus GT-P6200
– Samsung Galaxy Tab 7.0 Plus Wi-Fi GT-P6210

New in v2.15:
– Samsung Galaxy S GT-I9003L
– Samsung Galaxy S2 GT-I9100G

New in v2.35:
– Samsung Galaxy S2 SHW-M250K
– Samsung Galaxy S2 SC-02C

New in v2.40:
– Samsung Galaxy S2 GT-I9100M
- Samsung Galaxy S3 GT-I9300

New in v2.45:
– Samsung Galaxy S2 SCH-R760 (US Cellular)

Head over to the original thread to put your ORD to work!

782-galaxy-s3

XDA Elite Recognized Developer Chainfire has done it yet again. After being the first to root the device (sight-unseen, no less), Chainfire has released his nearly ubiquitous CF-Root for the device.

For the uninitiated, CF-Root isn’t a complete ROM, nor does it pretend to be. Rather, it is arguably the simplest entry point to superuser status on your mobile device. Geared towards those wanting to remain as close to stock as possible, flashing CF-Root replaces your original Samsung kernel with a rooted variant. In addition to substituting in a rooted kernel, CF-Root also features CWM Manager and the ported version of ClockworkMod Recovery we covered earlier.

According to Chainfire himself:

CF-Root is the root for “rooting beginners” and those who want to keep as close to stock as possible. CF-Root is meant to be used in combination with stock Samsung firmwares, and be the quickest and easiest way for your first root.

What’s installed
– Root: SuperSU
– Recovery: ClockWorkMod
– Util: CWM Manager

Kernel

Unlike CF-Root for some other devices, this iteration of CF-Root does not include a custom kernel. Your kernel remains the stock kernel, and thus goodies like insecure adbd (ro.secure=0), custom boot scripts, and custom boot animations are not supported.

Root – SuperSU
The root permission management app installed by CF-Root is SuperSU. This will allow your apps to gain root (superuser) access.

Recovery – ClockWorkMod (CWM)
A custom CWM 5.5 build is included in CF-Root, taken from this thread. This provides for the ability to install custom ROMs, and do nandroid (full device) backups and restores.

Util – CWM Manager
My management application for CWM is also installed, see the recovery thread linked above for further details. It allows you to command CWM (install a ROM, make/restore backups, etc) from normally booted Android.

Installation is incredibly simple. Simply use ODIN to flash the CF-Root package, and you’re good to go. Afterwards, you can use the newly updated TriangleAway, at least while it still works.

Continue on to the release thread to get started!

sammybrick

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-N7000Epic 4G TouchAT&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 0x19 revision was highlighted as known bad, whereas the 0x25 is thought to be safe. Revisions between 0x19 and 0x25 are thought to be possibly bad, whereas those newer than 0x25 are probably safe. Adding insult to injury, those keen on hex will be quick to notice that 0x19 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 0x19 –> known bad
MAG4FA, VYL00M, or KYL00M fwrev >= 0x25 –> probably safe
MAG4FA, VYL00M, or KYL00M fwrev != 0x19 && < 0x25 –> 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.]

CF_TA

Those familiar with TriangleAway by XDA Elite Recognized Developer Chainfire will take comfort in knowing that the app has been updated to add compatibility with the Samsung Galaxy S III and the International Galaxy Note. For those unfamiliar with the app, it does as its name implies by removing the triangle and resetting the flash counter on your device.

Let’s backtrack for a minute and find out exactly why the app had to be updated, and what made this time a little different than before. At the application’s start, the kernel flash counter was relatively easy to take care of. Simply resetting the value would remove the counter. However, with the release of the Galaxy Note, Samsung made things more difficult by hiding the data. And now on the Samsung Galaxy S III, Samsung has made it even more difficult thanks to a background service that searches for the telltale signs of rooting.

According to Chainfire’s development blog:

With the Galaxy S II, Samsung introduced a custom kernel flash counter and custom kernel warning triangle. This is where Triangle Away came in – it reset the flash counter and removed the warning triangle.
On the Galaxy Note, Samsung tried hiding the data once more, so Triangle Away would not work.
On the Galaxy S III (among other new devices), Samsung has gone a step further, and has introduced a background service that runs on your device and checks for things such as a modified /system, apps running with root access, etc.

For the moment, this service does not do anything malicious, but who knows what the future will bring ? Tracking of IMEI’s that have ever ran root, disabling of services, etc ?

Scary, isn’t it? The last line should jump out at you, as it’s not too much of a stretch to think that future revisions of the service could be used as such. And by looking at the update log, you can clearly see the battle between Chainfire and Samsung:

Update 16.02.2012: Users have confirmed TriangleAway works on the I9220 SGNote ICS leak !
Update 13.05.2012: TriangleAway does *not* work on the latest official SGNote ICS firmwares. There will be a fixed version soon, but it has to wait for my Note to return from repairs, else I cannot test it 
Update 04.06.2012: v1.50 should work with the I9220 and N7000 SGNote’s again

Right about now, you may be wondering why exactly Samsung or any other OEM would feel the need to keep tabs on your ORD. One can assume that it has to do with warranty, but is this really a valid reason on Samsung’s part? After all, if the hardware functioned properly, why should an improper firmware flash even have the capacity to damage the hardware?

Once again, according to Chainfire himself:

Custom ROMs, root, bricks, and warranty

I am not sure what the reason is Samsung wants to track all this. My reason for wanting to “break” their tracking is one thing: warranty.

Being able to run the software I want on devices I own without losing hardware warranty should be a right by law. As for as I can see, there’s only two ways you can really break your device with root access:

(1) overclocking to the point where hardware is damaged
(2) flashing nonsense to your bootloader partitions

I’m not sure how to handle (1). I personally never overclock – and I don’t think it’s strange to deny overclockers warranty. Surely this must be preventable in the hardware. Case number (2) however is wholly Samsung’s fault. Adam Outler has shown time and again that these devices are perfectly able to be made unbrickable – so any bootloader brick is IMHO Samsung’s fault. If Adam Outler can prevent the situation with a soldering iron, the original design is broken.

Regardless, hardware should be under warranty – if I have my device rooted or not. Leaked service center documents show that devices should be checked for root, and if present, deny warranty. (This is not just Samsung, all the major OEMs do this.)

That is simply unacceptable. Any OEM following that policy is a bad OEM – in some countries this may even be an unlawful practise (though good luck winning in court). HTC has once refused to replace a defective digitizer on my HTC Diamond (a common hardware issue with this device) due to HSPL being present. They claimed HSPL had irreversibly damaged the mainboard, and the entire innards of the device would have to be replaced. Riiiiight.

Root by itself is not a crime, nor a pointer that a device is broken in any way that should not fall under warranty. But in the eyes of the OEMs it seems we are criminals.

If the purpose of the tracking is related to corporate security and such, I can see why Samsung would want to lock down further. I can certainly understand that, though I don’t necessarily agree.

If this reminds you of the mid-nineties, you are forgiven. As Chainfire writes, there is nothing inherently malicious or criminal in being able to use our own devices as we see fit. Yet, various OEMs employ tactics aimed at preventing us from truly customizing our devices to our hearts’ content for fear of a voided warranty.

If (using Chainfire’s personal example) broken digitizer hardware has absolutely nothing to do with flashed firmware, why is that justification for denying warranty service. For those who tinker with their cars, this is akin to voiding a Powertrain Warranty because you added an aftermarket radio. There is simply no justification—morally anyhow. Luckily for those in the US, the Magnusun-Moss Warranty Act offers a sliver of protection—but good luck trying to take that to court. And in other countries, you may be entirely out of luck.

This then leads to the question of what would be best, both practically and ethically. Chainfire has assessed the situation stating:

And thus we come full circle – if Samsung goes another step further in protecting their custom flash data, will I even attempt to bypass it ? Should I ? A big part of me thinks not.

Those simply looking to absolve their triangle and flash counter for what is possibly the last time can purchase a donation version of the app on Google Play or head to the original release thread for the free version. Those simply looking to learn more on the issue should head over to Chainfire’s development blog post.

 

ClockworkMod-Recovery-3_thumb

Samsung Galaxy S III this, SGS3 that—it seems like everywhere you look, the mobile tech industry is aflutter with news on Samsung’s latest flagship. Fittingly, there has also been a plethora of development surrounding the device—everything from achieving root access and the release of GPL-compliant kernel source to its launcher and proprietary apps ported to other devices.

We now have a custom recovery thanks to XDA Elite Recognized Developer Chainfire, who coincidentally was the first to root the device sight-unseen, well before official release. The recovery itself is an unofficial port of ClockworkMod 5.5. 0.4. Due to the way CWM works, there were a few quirks along the way. However, Chainfire seems to have squashed them, and tells us:

As is the case with every SGS release (it happened with the SGS1 and the SGS2, and now again with the SGS3), CWM source isn’t built to correctly deal with our setup (internal storage vs sdcard). I had to make a number of changes to the source to get it working correctly. From my tests, it all seems to work, but it’s quite possible I missed something (report issues).

(I have tested backup/restore to both internal and external storage, wipes, installing zips from both internal and external, etc, all works as I expect it to)

Aside from the base fixes, there is currently nothing fancy about this build of CWM. I’m not sure if the SGS3 suffers from the brick bug (that SGS2 and Note have), but I patched out the relevant code to be sure (I think). Backups are rather big, system alone is about a GB.

Those lucky enough to own the SGS3 already, or those eagerly awaiting their own, should head over to the recovery thread.

[Big thanks to Member Advocate Admin Egzthunder1 for the tip.]

Advertisement

XDA TV: Most Recent Video

Buy/Sell on Swappa

  • Nexus 5 (Unlocked) buy | sell
  • Galaxy Note 3 (T-Mobile) buy | sell
  • HTC One M7 (Verizon) buy | sell
  • Galaxy S 5 (Unlocked) buy | sell
  • Nexus 7 2013 buy | sell
  • Swappa is the official marketplace of XDA