yashsingh1/xdaforums huggingface dataset:
[Nexus 7 General] GedBlake:
Hi, vorcers...

Yep... I also think that flashing via OTA is safer. Given that this is how 99.9% of all Android users get their updates, (ie, not via the factory images). I would imagine there would have been a bit of an outcry, had faulty bootloaders delivered by OTA updates, bricked a lot of devices.

Also, it's my understanding that OTA's updates bootloaders by 'dropping' a temporary copy (BOOTLOADER.RAW) into a sort of a temporary 'holding' partition (USP/Staging)... prior to it being 'copied' to the bootloader partition proper. I'm guessing some sort of checksum or other similar test is performed on the two bootloaders... the current (old) one, and the (potentially) new one (held in the USP partition), to ensure compatibility.

However, when you fastboot flash a bootloader, you're directly writing OVER the current one... if it's garbage you're writing, you have a dead Nexus. Still, having said that, it's probably a bit more complicated than my possibly over simplified account.

One things for sure, though... never fastboot flash a bootloader... unless you really need to:).

I ran the flatline procedure a couple of months ago, and it was a hugely nerve wracking experience. Fortunately, it went without a hitch, and I'm back on bootloader v4.23 (from build JWR66V)... and I now have my 'wheelie' blobs, safely stashed away in a variety of locations:).

Testing them though, is something I won't be doing... for tolerably obvious reasons:):):).

Rgrds,

Ged.
[Nexus 7 General] AndDiSa:
Flashing a bootloader by fastboot will not overwrite the current one immediately, but it will be flashed on reboot, i.e. the bootloader updating process between fastboot and OTA is almost the same ... beside the possibility to correct a mistake (i.e. flashed a wrong bootloader) as log as you do not reboot your device.
[Nexus 7 General] GedBlake:
Thanks, AndDiSa...

You know... I'd quite forgotten about that:).

But isn't that because the new faulty bootloader (or some other random garbage) HAS actually been written to the eMMC chip, but the old working bootloader is still loaded into memory/RAM	(ie., you're still in fastboot mode)... affording you a very slight window of opportunity to reverse or correct the mistake... providing the device isn't rebooted.

The old bootloader is still there, but it's now only stored in 'volatile' memory...

Rgrds,

Ged.
[Nexus 7 General] bftb0:
Hi Ged

First, I should say that your comments here were what encouraged me to check all the (grouper) bootloader images from the Google "factory images" - it triggered a recollection that I had noticed a length difference between the OTA and fastboot versions of the bootloader files some time ago, so I went back and took a look. Thanks for giving me the incentive.

Warning - a bit of a [thread-jack] ahead:

There is a comment in that Flatline - Unbrickable Nexus 7 (Wi-Fi + 3G) thread to the effect of:

... but trying to read between the lines, I can not determine if Xcandescent's claims only apply if you leave the "patched" version of the AndroidRoot.Mobi bootloader on the device, rather than using nvflash itself to put back a "stock" bootloader. Reading between the lines, it sounds like subsequently you have not tried using fastboot for flashing a bootloader... do I have that right?

I guess I will put up a question on that thread and see if rayman or lilstevie respond... [/thread-jack]
[Nexus 7 General] GedBlake:
Hi, bftb0...

It's good to see you around again. I must admit, that most of the stuff you post, I really, really don't understand:confused:... but I always learn something new:).

Concerning flatline... Well, I ran it sometime back in October...

I knew beforehand that there where known issues concerning fastboot flashing the bootloader from build JWR66Y (ie, it won't fastboot flash) so now I ALWAYS keep a copy of the v4.23 bootloader from build JWR66V stored on my laptop... which came in useful for the flatline procedure.

The whole procedure revolves around flatlines Custom Recovery...

Once I'd fastboot flashed the specially modified Flatline Custom Recovery (which is based on CWM) to the recovery partition, I then went into the ADVANCED option... and selected option 1: flash AndroidRoot BL... this flashes the AndroidRoot Custom Bootloader - (you don't actually flash this yourself - the Flatline Custom Recovery does it for you).

Following the instructions to the letter, I then booted normally into Android.

I shutdown my Nexus 7 completely, and rebooted into this modified AndroidRoot bootloader in fastboot mode... to discover that the version number had been 'downgraded' to v4.13. Nothing there signifies or indicates it is in fact the flatline AndroidRoot BL... it just looks like a regular v4.13 bootloader.

After selecting the RECOVERY option in this modified bootloader, as you would normally, to get into either standard CWM or TWRP, it boots back into the Flatline Custom Recovery again.

Selecting the ADVANCED option again... I now choose option 2: generate wheelie blobs... these blobs were then generated, which I subsequently found in /data/media/AndroidRoot on the Nexus 7 itself. Having made multiple copies of them, it was then just a matter of closing the operation by doing two things...

*** fastboot flashed back to the normal v4.23 bootloader from build JWR66V...

...and after a normal reboot...

*** fastboot flashed back to the version of TWRP I was using at the time...

A summary

1). I fastboot flashed the special Flatline Custom Recovery.

2). In this special Custom Recovery, in the Advanced menu option, I selected option no.1... it flashed the AndroidRoot v4.13 bootloader.

3). I rebooted normally into Android.

4). I rebooted into the Flatline Custom Recovery again (via the bootloader).

5). In the Advanced menu option, I selected 'generate wheelie blobs'.

6). Once generated, I copied them from /data/media/AndroidRoot .

-- Now to return everything back to normal...---

7). I fastboot flashed the regular v4.23 bootloader from build JWR66V.

8). I fastboot flashed the version of TWRP I was using at the time.

I didn't need to use nvFlash to restore the standard bootloader... I just used the standard fastboot flash bootloader bootloader.img syntax, to reflash v4.23.

And that's pretty much it really... obviously I haven't had the opportunity to test out those 'blobs'... and hopefully, I'll never have cause to:).

Hope this helps.

Rgrds,

Ged.
[Nexus 7 General] bftb0:
Thanks!
[Nexus 7 General] TToTT:
A download of that file can be found here, just as an FYI.
[Nexus 7 General] iamelton:
i have fastboot flashed the bootloader image from KOT49H, and it *seems* to be working fine..

what could be the potential issue here, a possible future brick?

is it better to flash back the bootloader image from KRT16S as suggested by the OP?

tia..
[Nexus 7 General] bftb0:
Are you sure it actually got flashed?

Others have reported "signing errors" relating to bootloader flashing in the past, so I suppose it is possible that some form of sanity checking is performed by the existing bootloader. Meaning, that the fastboot flash command actually does transfer the image file to the tablet (probably into RAM because it is a fairly small file) but if it doesn't pass those sanity checks, it never really gets burned to the eMMC chip by the pre-existing bootloader. Unfortunately, because the bootloader is proprietary, we don't really know what is checked and what isn't.

(I think most folks who hard-bricked their tablet either *erased* their bootloader using fastboot and then rebooted before they had flashed something, or else they accidentally over-wrote /dev/block/mmcblk0p{0,1} from a root-privileged process inside a booted ROM or recovery)

If your tablet is working I wouldn't fix something that isn't broke.

But as I said, I'm pretty confident that whatever that thing is in the KOT49H factory image, it is NOT a valid bootloader.

$ strings -8 nakasi-kot49h/bootloader-grouper-4.23.img > kot49h-strings.txt
$ strings -8 nakasi-krt16o/bootloader-grouper-4.23.img > krt16o-strings.txt

$ wc -l *-strings.txt
4363 kot49h-strings.txt
1935 krt16o-strings.txt
6298 total

$ cat kot49h-strings.txt | sort | uniq > kot49h-strings-unique.txt
$ cat krt16o-strings.txt | sort | uniq > krt16o-strings-unique.txt

$ rm *-strings.txt

$ wc -l *-strings-unique.txt
3839 kot49h-strings-unique.txt
1797 krt16o-strings-unique.txt
5636 total

$ cat *-strings-unique.txt | sort | uniq | wc -l
5611

$ cat *-strings-unique.txt | sort | uniq -d | wc -l
25

(Interpreting the above: there are 1797 unique ASCII strings (out of 1935) of length 8 or greater in the KRT16O version of the file; and there are 3839 unique ASCII strings (out of 4363) of length 8 or greater in the KOT49H version. And only 25 matching strings between the two of them!)

There's really only two plausible explanations for that:

- That Google/Asus completely replaced their bootloader code - and gave it the same name! -OR-

- That blob in KOT49H isn't a bootloader.

cheers
[Nexus 7 General] iamelton:
the strange thing is that i flashed both the JWR66Y and KOT49H version bootloaders..

the JWR66Y one did give me a flash error (something like unable to overwrite) during the process, however, the KOT49H gave me a success result..

therefore before finding this thread i was under the impression that my n7 was using the KOT49H bootloader happily..

but now im a bit confused..

anyway as u suggested, theres no need to fix something thats not broken..

and probably in future i shall not flash bootloaders so promptly (or maybe better not to flash at all unless necessary..)
[Nexus 7 General] s107ken:
Hi, this weekend I flashed bootloader to my own N7 2012 3G(tilapia) many times.

Describes in summary (but too looong), attached full report.

I found JDQ39(4.2.2) and KRT16S(4.4) are only correct bootloader file?

Grouper and Tilapia uses same bootloader.img?

What happen google / asus software release?

TILAPIA (N7 3G, 2012) BOOTLOADERS
DERIVED FROM Google "Factory Images":
BYTES MD5SUM	ROM FACTORY_IMAGE_FILENAME strings *.img | grep BOOTLOADER

2146892 bffa744a6847b5bede2bf445427ef80e JDQ39 ./nakasig-jdq39/bootloader-tilapia-4.18.img BOOTLOADER VERSION - 4.18
- - - - - - JWR66V (I don't have this factory image) - - -
2151068 5bdb2e87370cdb1a7ea14bb0c3e21390 JWR66Y ./nakasig-jwr66y/bootloader-tilapia-4.23.img BOOTLOADER VERSION - 4.23
- - - - - - KRT16O bootloader & radio image didn't contain!! - - -
2150992 df53028033c9eccf4fe5ba7bc198ce24 KRT16S ./nakasig-krt16s/bootloader-tilapia-4.23.img BOOTLOADER VERSION - 4.23
4005632 797a8ddfe19bfe4c485f8a8c119f1bdd KOT49H ./nakasig-kot49h/bootloader-tilapia-4.23.img BOOTLOADER VERSION - %s

JDQ39, KRT16S succeeded flash bootloader

nakasig-jdq39# fastboot flash bootloader bootloader-tilapia-4.18.img
sending 'bootloader' (2096 KB)...
OKAY [ 0.338s]
writing 'bootloader'...
OKAY [ 1.230s]
finished. total time: 1.569s

(bootloader screen left-top) "Signature match."

JWR66Y, KOT49H failed flash bootloader

nakasig-jwr66y# fastboot flash bootloader bootloader-tilapia-4.23.img
sending 'bootloader' (2100 KB)...
OKAY [ 0.335s]
writing 'bootloader'...
FAILED (remote: (InvalidState))
finished. total time: 0.469s

"Signature mismatch."
[Nexus 7 General] bftb0:
Thanks [MENTION=5202125]s107ken[/MENTION]

It is reassuring to know that the pre-existing bootloader performs signature checking against the file blobs when using fastboot.

I presume the same thing happens when the OTA version of the bootloader is dropped into the staging partition - the pre-existing bootloader has the opportunity to examine it for validity.

But if someone were to flash a bad blob directly from a root shell using "dd" they will certainly hard-brick their N7.
[Nexus 7 General] andogeek10:
Doubts

Hey guys, I've got a few questions relating to the bootloader, its versions and nvflash.

Hopefully by the next week I'm going to be a proud owner of the Nexus 7. I'm not new to the android world or flashing. But, it'll be a new experience for me to own a nexus device. I own a Xperia Mini Pro (Sony Ericsson) where the only fastboot command used is the command used to flash kernels, so all this talk about using fastboot to flash bootloaders, baseband etc. is definitely a big change. So pardon me if make a mistake or ask a wrong question.

I'm confused about a few things :

i) If I update my android version using the OTA feature to 4.4.2 (KOT49H), it would also flash/update my bootloader, right? So, according to this thread the bootloader included in that update is not right (or doesn't work properly?:confused: ) and then would I be required to flash the bootloader image from the KRT16S update?

ii)I was reading through the flatline thread, and initially it seemed amazing that by generating a few blobs, you could unbrick your device. But, after reading a few pages ahead it seemed that many people were facing problems and it now seems a dangerous procedure. So my question is: Is it really recommended that an individual generate those blobs and by doing so, follow that nerve racking procedure?

iii)If I were to flash a custom kernel, would it include a custom recovery or would I have to install a custom recovery using fastboot. And if the custom kernel will include a custom recovery, will overwrite the existing custom recovery?

Thanks a lot.
[Nexus 7 General] andogeek10:
Thanks a lot for clearing these doubts of mine. Yes, the 2012 version is still sold ( at least in India it is ) and is much cheaper than the 2013 version.

2012 Nexus 7 - INR 9100

2013 Nexus 7 - INR 21000

And yes, i do know the difference between Nexus 7 2012 and 2013 (at least the major ones :P).

About the nvflash blobs generation, I've decided to not do it as I would be directly updating via OTA to 4.4.2 and then unlock the bootloader. Also, I would be updating via OTA only in the future, so I will not flash the bootloader by fastboot ( and hopefully reducing the risk of achieving a brick).

I was confused about the kernel and recovery as in the 2011 Xperia devices, there is no separate recovery partition and thus the recovery changes with every kernel flash.

I had read through most of the sticky topics and these were the only doubts remaining. Thanks again for clearing them.
[Xperia Z Q&A, Help & Troubleshooting] JamerTheProgrammer:
My friend (elderly) gave me her Xperia Z so I could get her sim setup. Because I have been getting over 2 nights up straight, watching my dog (he has neurological issues and I am nursing him currently) I was really tired and accidentally put a micro sim adapter in the sim slot the wrong way up. Its now well and truly stuck in there. It started out being stuck half way (the hole wasnt coliding with the pins though so hopefully they arent damaged? then i pushed it in completely in the hope of maybe hitting an ejecting mechanism, no such luck. Im taking it to a local repair shop. Im really worried (she knows and isnt worried lol) that one of the pins might have been snapped off? I have tried shaking it about and I cant hear any rattling at all (maybe theres not enough room for it to do so even if it was the case) so maybe thats a good start. I did apply a bit of gentle force to pull it out but I didnt feel anything break or hear any snaps.

If I did break a pin, how much do you think it will cost for an independent phone shop to repair it for me? I dont mind paying the fee because its through my negligence.
[Xperia Z Q&A, Help & Troubleshooting] ooohhaaahh:
probably would be cheaper to buy one used or online
[Xperia Z Q&A, Help & Troubleshooting] Richy99:
when I had mine I put it in the wong way, got it out using a flat ended knife without any damage to the sim or phone
[Xperia Z Q&A, Help & Troubleshooting] ooohhaaahh:
that was in response for if he damaged the sim slot and going to a shop.

he could probably get it out with an x acto knife, they're pretty thin
[Xperia Z Q&A, Help & Troubleshooting] JamerTheProgrammer:
Managed to get the guy round at the shop to get the back off for me and I have done the rest. I have now cut off the end of the adapter and I can happily report that NONE of the pins are broken! Great news. Now i just need to figure out how to get it out because the rest is still stuck. If I cut the one side more than the other I might be able to rotate it out.
[T-Mobile Samsung Galaxy S 4] freddyraptor:
Im not sure if it even signal dropping or wht. when ever im opening the dialer the signals are vanishing even though calls go through. But if i make one more attempt of dialing it says no network.

Data is fine, havent seen any drop yet. any help will be greatly appreciated thanks.
[T-Mobile Samsung Galaxy S 4] xdapowerapps:
Flash the 4.3 modem through Odin or MobileOdin. Should fix the issues you are having. Search for "4.3 modem" and you'll find it.
[T-Mobile Samsung Galaxy S 4] freddyraptor:
hey dude, i cannot find it. help a noob here please.
[T-Mobile Samsung Galaxy S 4] lordcheeto03:
It's that white text box in the upper-right hand corner. :D

http://xdaforums.com/search.php?searchid=241389664
[T-Mobile Samsung Galaxy S 4] freddyraptor:
thank you sir
[Nook HD, HD+ Q&A, Help & Troubleshooting] Jmoon:
Specs:

B&N NookHD+

Android Version 4.3

Kernel Version 3.0.31-green+

build03@cyanogenmod #1

Fri Aug 30 05:35:43 PDT 2013

CyanogenMod version

10.2-20130830-NIGHTLY-ovation

First off, thanks to those who respond with help to my situation. I definitely appreciate it.

Problem: I bought a NookHD+ off of craigslist as an affordable alternative to a tablet PC. I'd like to watch some episodes of netflix and hulu and youtube on my TV with it. I bought the HDMI adapter for the NookHD+. Unfortunately it's not working and I think it's because it was flashed?/rooted? to a different OS. This is not booting from a memory card, it's booting internally. I'm not an expert with these so the boards are a bit confusing when it comes to rooting, etc. I have tried two different fairly new TV's. The TV's do not even sense an input signal.

Questions: Shouldn't I just be able to connect the HDMI adapter and have output even with the CyanogenMod OS? If so how? If not how do I get back to the original NookHD+ OS? Any other ideas as to why the HDMI output is not working?
[Nook HD, HD+ Q&A, Help & Troubleshooting] :
Edit: It appears that it should be possible with cm on the nooks. It is searchable as I know it was brought up before. I was thinking about mhl which doesn't work.

Also it looks like your on a terribly old and gimped 10.2 build. Could also be your problem. Update to the latest.

leapinlar I believe has a way to go back to official bn rom in the event you didn't create a backup. If you did [create a backup] it could be as simple as rebooting into recovery, backing up, wiping, then restoring.
[Nook HD, HD+ Q&A, Help & Troubleshooting] Jmoon:
Thank you, I will try to update the build to the latest one first.
[Nook HD, HD+ Q&A, Help & Troubleshooting] Jmoon:
Just updated to the latest build and found two things:

1. My nook is operating much better

2. That HDMI adapter has to be surgically attached in order to function. Literally if it moves a little bit the TV will lose signal. That was probably my main issue but the update helped too.

Thanks again for the assistance.
[PDA2, XDA IIi, 2020i Software Upgrading] longnguyen30:
does anyone know when will we get w2005 for 02i. I have been waitting for that rom.
[PDA2, XDA IIi, 2020i Software Upgrading] andy-c1:
dude read the forum please..... no wm2005 for xda2i
[PDA2, XDA IIi, 2020i Software Upgrading] radenferdy:
only updating ROM I guess...
[PDA2, XDA IIi, 2020i Software Upgrading] xplode:
There is no WM5 Rom for alpine, and it is almost impossible to create one , please read this thread

There were attempts to port Universal rom but they were unsuccessful
[G2 Q&A, Help & Troubleshooting] trajin:
i back up my phone with the lg back up, and it backup, but now when i try to restore the file it says the backup is damaged! is there any way i can fix this????? really need help thanks in advavnce.
[G2 Q&A, Help & Troubleshooting] comk4ver:
You're not rooted right?
[G2 Q&A, Help & Troubleshooting] trajin:
no trying stock for the moment
[G2 Q&A, Help & Troubleshooting] comk4ver:
Reflash go back to original stock then do a backup. Or try deleting the old backup then try again but if I were you I'd make sure you have a fully charged battery.
[Android Q&A, Help & Troubleshooting] klau1:
I just discovered a new permission request "Android System" UID System User 1000 in SuperSU .

I can't explain where this comes from.

So I did the following:

1.) Factory Wipe

2.) ODIN and simply flashed the Stock ROM with 1 file ROM in PDA slot

One thing I didn't do was Format the System Partition

But the next time I install SuperSU the permission request appears again.

So I want to know, does ODIN flash and Factory Wipe, truly wipe everything?
[Android Q&A, Help & Troubleshooting] LordManhattan:
You didn't wipe everything. You didn't wipe the system partition where the su request came from.
[Android Q&A, Help & Troubleshooting] klau1:
Thanks, I thought the TAR.MD5 Odin ROMs clear out everything in the system partition before writing.
[Android Q&A, Help & Troubleshooting] klau1:
Weird, even after going into Touch CWM and doing the following:

1.) Factory Wipe

2.) Clear Cache

3.) Clear Davlik Cache

4.) Mounts and Storage > Format /System

5.) Reboot to Bootloader

6.) Loaded ROM via ODIN N8010XXUCMK2 http://www.android-hilfe.de/origina...jellybean-4-1-2-20-11-2013-a.html#post6823310

7.) Loaded Touch CWM

8.) Installed SuperSU zip

Upon the second restart, it again requests for root from Android System UID User 1000
[Android Q&A, Help & Troubleshooting] LordManhattan:
Huh.. strange. You wiped everything this time so that's weird. I've never seen a su request from Android System (the android system has root as default, as an OS should have). I'll dig a little and i'll be back soon.

UPDATE: I think i cracked the case. It's Xposed that does this on Samsung devices. If you do not use Xposed, it could be SuperSU. Be sure to have the latest version installed.
[Android Q&A, Help & Troubleshooting] klau1:
If you are referring to this:

The device is on one of the latest SuperSUs 1.80 and then updated to 1.85, and never on SuperSU =< v1.69

Regarding the System User Request, Is below what you are referring to?

If I understand this properly, it's saying SuperSU accesses some functions as the System User 1000 on Android devices previous to OS version 4.3

On Android 4.3 and newer, SuperSU access those same functions without using System User 1000.

This would explain why this permission request does not appear on my Android 4.3 device, but it does on my Android 4.1.2 device.

Is this the correct understanding?
[Android Q&A, Help & Troubleshooting] cernekee:
Internally, Superuser/SuperSU can switch UIDs to execute different subprocesses with different user credentials. But these do not generate requests that you would see on the screen.

To track down the source of the request, can you run these commands from a PC while the SuperSU dialog for "Android System" is on the screen, then paste the results?

adb shell busybox ps -Tl
adb shell ps
[Android Q&A, Help & Troubleshooting] klau1:
Here it is:

Attached

The command output of "adb shell ps" is also inside, just search for "adb shell ps" in an txt editor to jump to it.
[Android Q&A, Help & Troubleshooting] giannism13:
Although, I'm a noob I will try to help. If I mind correctly , If you go supersu > setting is a checkbox that says something about "system processes" or similar, make sure that is unchecked. You could also try emailing to the developer of supersu, your rom and kernel
[Android Q&A, Help & Troubleshooting] klau1:
I know that, but just indiscriminately "trusting" the user doesn't make it safer. Just like keeping your doors open so you won't hear anyone break in doesn't stop the actual breakin from happening.

And it's also a stock ROM from: http://www.android-hilfe.de/origina...jellybean-4-1-2-20-11-2013-a.html#post6823310

Is it possible these Stock ROM uploads are infected with malware?
[Galaxy Note 3 Accessories] flipq88:
Delete