yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] Woody:
I'll see what I can come up with. What I really want is for some creativity in how we are to get at this. See my few posts back about the 2 directions we could go.

I am trying to get my hands on an Encrypted Vibrant to do some tests but when people get the error they tend to thrash their phones in a fit of rage or they try to "fix" it and make it worse. Since I don't own a Cappy I don't have any files or hardware but Android O/S is O/S so code is code. So if you or I can find a solution it should work for both.

ps - Thanks for the PM Jeff.

My feelings weren't hurt bc of an anonymous random post in an international multi-segregated developers forum about something that effects us all, but he kind of had a point too. Ill stick around but I need some more imagination on everyone's part and need someone else with ADB experience to test some ideas.
[Captivate Android Development] lactardjosh:
Maybe cross posting this in the general Android Development forum would get more exposure.

(I have not encountered the issue myself yet on my Captivate. It's got CM9, but I'm not using MTP. I've been following this from pretty early on though.)
[Captivate Android Development] jeff.leonard:
I didn't "thrash" my "encrypted" Captivate but I did attempt to remove the internal battery (small one on the board) and now it doesn't seem boot. It looks like I may have just broken a solder joint; I should have time Monday to re-solder it and try again. Imagine if the phone is fixed after simply removing the internal battery and putting it back; that is what I was hoping when I originally tried to remove it.

Also, thanks for sticking with us here.

---------- Post added at 07:05 PM ---------- Previous post was at 07:03 PM ----------

When you say you are not using MTP do you mean not connecting to a PC or you are forcing it to use USB Mass Storage mode instead of MTP?
[Captivate Android Development] Woody:
I have been searching other device forums most of the day and the General/Q&A XDA pages too. Not too much out there except how to encrypt your emails or sms. I'm going to go off the grid and look into some other sites and see if they have anything.

I'll get back in a few days to share what I have found (if anything).
[Captivate Android Development] jcjcc:
Agree, it shouldn't have anything to do with MTP or mass storage. First of all, when my movinand failed it was totally at random, and secondly, USB mounting (whether MTP or mass storage) accesses mmc0 on the filesystem level. It doesn't even access at the block level (since /data is also on the same block device), much less the SD/MMC hardware interface level.
[Captivate Android Development] jeff.leonard:
While it may not make sense; there is a pattern of failure following connecting with MTP on the

next

reboot. I can think of 5 users that have described this exact scenario plus myself; this is the best theory I've heard.

I believe it enough that I am back running ICS on another Captivate, just not using MTP; working great so far (that knocking sound you hear is me knocking on wood:D).
[Captivate Android Development] lactardjosh:
It's using USB Mass Storage when I connect to my PC.
[Captivate Android Development] RootTheMachine:
It was CM9 build 16. There was an external sd present, but I removed it and did a factory reset to fix it

Sent from my CM9 ICS i897 Captivate
[Captivate Android Development] jeff.leonard:
Thanks, mine is configured that way but I haven't connected it yet; this makes me feel better about doing it.
[Captivate Android Development] Woody:
There is either a build.prop or default.prop edit that you can make it so that when connected it will connect via Mass Storage and not MTP. I have a ROM at home on my HDD that I know for sure does it this way.

I'll pull it and let you know later on tonight or tomorrow. Just pulled a 13hr shift, so I am a little fried right now. One of our ROMs that has had the far fewest Encryption Errors does it this way. As a matter of fact, there is only 2 confirmed using that ROM that got the error and both came from AOSP or CM9 base before.

I understand that not everyone believes this and that is fine. That actually pushes the research further by having a few doubters. And I am not saying that MTP is the sole culprit. It's just a theory. But a theory with a lot of coincidences wouldn't you say.
[Captivate Android Development] lactardjosh:
It's default.prop.

persist.sys.usb.config=mass_storage,adb
[Captivate Android Development] silvertag:
I did some digging around and read through part the MTP protocol from Microsoft doc, nand, yaffs2, yaffs corruption ,etc. So far i think we just hit the tip of the iceberg and by reading more i found 2 things.

1) There's alot we still don't know and need to test.

2) the more i read, the more i see myself digging a hole in technical details that go behond my grasp and technological knowledge.

That being said here is what i think is happening from what was reported so far about the MTP issue.

Scenario:

-User sets his MTP ON or is set ON by xxxx.prop file.

-User reboots with phone plugged to pc, get an encryption error even without having transferred any files by MTP.

-User gets a internal sd brick.

Presuming what's going on:

MTP is active and linked to pc.

PC OS detects the device and links with the device.

MTP see the pc and exchange information.

MTP mounts internal/external sd as drive for the pc and remains active for phone.

Phone is rebooted but is still connected.

Reboot severs the link but MTP did not get disconnected from the pc request and stays in a connected state thus leaving the present state of access to both

sd. (I know that MTP is able to handle this kind of error but something is going wrong here)

Android system unmounts the sd with the MTP current state active

Android runs it's init and tries to mount the internal sd

Android cannot remount the data block because of MTP state locking up its access.

Android presumes the encryption is active

Android tries to read the encryption block to decrypt and remount the data

Android cannot read the encryption block because it's not set and presume encryption went wrong.

Android throws the towel and declare a Encryption Unsuccessful error

User now have a brick internal sd.
[Captivate Android Development] bballer182:
I have this already in my default.prop on stock aokp build 33. Does this mean I connect to PC with UMS by default? How does one switch between MTP and UMS? With the default.prop?

@silver, I thank you for your time and investigation. Hopefully we (everyone who knows stuff) can figure out a solution and possible a fix for the borked.
[Captivate Android Development] DaNaRkI:
Most of that sounds to me like a Google problem.

Some of it sounds a little past what's really necessary for file transfers. Since you said the stuff is too technical can you PM me some links, or post your sources to ease the work for others.

But the main problem, is no one said they got a reboot while connected. The reboot comes some time later, maybe days later. Tho the possibility of MTP not property disengaging, may still play a roll.

leaked from my

ICS

- FUSED SGS I897 contaminating you via XDA app.
[Captivate Android Development] silvertag:
Yes you are set as UMS as default. If it was persist.sys.usb.config=mtp,adb you would be MTP by default..that's the bad thing and Woodrube already identified a few roms set to this.

You can either switch manually (menu/setting/storage -> menu/Usb computer connection), by apps or adb shell cmd. I recommend you stay as UMS to be safe

UMS by default takes ownership of the partition when it's mounted, even the android os cannot access it until it is released. MTP in the other hand shares it both way with android and the pc except it cannot modify files so you need to download them to modify them.

---------- Post added at 12:24 PM ---------- Previous post was at 12:18 PM ----------

Yes i did summarize pretty quick but yes some did not have the phone connected when they rebooted and faced the same issue. This makes me believe that MTP is not disengaging properly when disconnected and keeping things wrapped up until the fatal reboot.

http://en.wikipedia.org/wiki/Media_Transfer_Protocol

Introduction to MTP
[Captivate Android Development] Woody:
This is where I think the problem lies. Since MTP is mounted, something isn't disengaging when you unmount and pull away. Why? That is the question. I think the more we find out about this, the better chances we have to hopefully repair.

Nice work Silver. I read something this morning about how when the MTP is engaged and the something happens and it becomes disengaged by chance or power problem, the phone can't tell that it isn't still connected to the PC and thus, for simplest terms Android and Windows aren't reading each other and the weaker system shuts down and saves it's data by encrypting it. Like I said that is extremely simple terms and I'll try to find that link again to post it here.

Noce work everyone.
[Captivate Android Development] jmtheiss:
Is the setting for UMS/MTP something that can be set in the flashable ROM file, so that this can be set to UMS by default right out of the gate (meaning the user has to knowingly switch to MTP)?

If so, perhaps we can nudge the developers to include this fix in future rom updates.
[Captivate Android Development] Woody:
Yes it can. I'll have to pull my raw ROM apart and see where the default.prop lies in the zip. Shouldn't be too hard but I am at work and you know how that goes.

The ICZen ROM I am running has it set like that at default, so that is making me think that the two people that I know that were ruinning that ROM that got tagged, were coming from another AOSP ROM that had MTP set and they never actually booted up into Zen. Just mounted to PC, moved Zen.zip over to external (I asked both of them), unplugged and booted into CWR to flash. Flashed the ROM but the damage was already done to the internal and got the Error on first boot.

I gotta step out for awhile, my tablet just got an update and seems to have broken more for some than it fixed. So I am troubleshooting over there today. Keep up the good work. If anything, I appreciate it.
[Captivate Android Development] mr_psycho:
I believe there are at least three (3) different ways to handle setting the mass storage mode for USB connectivity (mtp or mass_storage).

1. default.prop - This is done via the kernel ramdisk. The Rom inherits the contents of the ramdisk's default.prop file and creates the Rom's /default.prop file. Kernel developers control this.

2. build.prop - I believe this overrides what is in the ramdisk's default.prop. Rom developers control this.

3. App/CLI command - Whether this is handled by an app (eg. USB Mode Switcher), or manually via the setprop command, the user must knowingly change the mode. The setting appears to be stored in the /data/property/persist.sys.usb.config file. Users have control.

Eg. Via ADB shell or Terminal Emulator:

setprop persist.sys.usb.config=mtp,adb

This method takes precedence over both default.prop and build.prop.

Unfortunately, I'm not absolutely sure whether it is default.prop that takes precedence over build.prop, or the other way around. In a worst-case scenario, it's possible that kernels could impact the way storage devices are mounted without the users' knowledge.

In the case of the Ice Cream Zenwich rom Woodrube mentioned for the Vibrant, "mass_storage" mode is being set in both build.prop, and default.prop (via subZero kernel ramdisk). Therefore, by default, a Zen user will always be in USB Mass Storage mode after installation of the Rom. On this particular rom, the user must knowingly change to their storage mode to MTP.

MP
[Captivate Android Development] stayintwisted:
well I was thinking,, has this happened to a phone that has had the "unbrickable mod" done to it,,or would having the unbrickable mod done after this happened to a phone allow the programming to be messed with at an early enough point in the boot process that you could change the response android is getting from the internal memory? ( I realise I don't really understand this whole process but it was just a thought)
[Captivate Android Development] silvertag:
@mr_psycho & all

I believe the default.prop take precedence over the build.prop. I have the UMS option set in the default.prop but not in my build.prop.
[Captivate Android Development] mechanical tool:
A phone was sent to AdamOutler and he was unable to fix it. The discussion wasn't too far back, probably in the last 10 pages.
[Captivate Android Development] BxingFetus:
Is the encryption issue, whatever still causing it, happening even with the later builds of cm9 and aokp. seems as though people who still have their internal sd card working don't seem that worried about it, or is flashing ics still like playing Russian roulette?

From the land of defrag
[Captivate Android Development] silvertag:
ICS at large is at risk (cm9, aokp,aosp, stock, etc) when you enable MTP and connect it to a pc. Your next reboot may be your last.

For now UMS is the safest mode.
[Captivate Android Development] swayjd:
This is false.

We don't know for sure that this is the cause.

As far as we know the issue is still out there, developers never mentioned it outside this thread.

Although it seems that there aren't any new cases lately, or people just don't report it.
[Captivate Android Development] jonnyg1097:
I got this one too as I reported in this thread here http://xdaforums.com/showthread.php?t=1619614.

And it seems to me that everything that was being said in this thread has happened to me also (ie: using CM9 alpha at one point on flashing on the phone)
[Captivate Android Development] daskanda:
So if you get the encryption unsuccessful screen but don't click the reset button can your phone still be unusable?
[Captivate Android Development] BxingFetus:
ok i see. thanks.

From the land of defrag
[Captivate Android Development] jmtheiss:
The answer is a solid "maybe". Some people, myself included, have gotten back from that screen. Others haven't been so lucky.
[Captivate Android Development] Woody:
You are somewhat correct here. We DON'T know for sure that the MTP theory is the cause. Many people are exibiting the symptoms before the error gets thrown, so that is pointing us towards MTP being part of the coup against us.

We (Vibrant Users) got about 5 more people hit this week. One was using an extremely stable ROM and he has been a very active member (so he knows what he is doing) and got hit out of nowhere.

I have found a new symptom. Might not be much but could be something of an indicator.

Many people state that right before the error gets thrown, they see (if it is out in the open and not in your pocket or bag or something) the screen darken. Jonny, I read your thread over there and as soon as I saw you mention that it darkened right before you got the error, a light went off in my head that I have seen this before (many, many times actually). It was even mentioned by Yosup (the person I posted above about). He actually said his screen was darkened before the reboot and he got the error. You two could have been posting the same file note.

So what does this tell us? Is the darkened screen a warning of some sort or is it a symptom of what is happening right before it happens? WHY does the screen darken right before the error? If you pull the battery while it is still darkened, can you bring it back to life? What did the few who were able to sidestep the error do when the saw the screen darken and rebooted? How? I know there were maybe two in this thread that were able to get it back and at least 1 on the Vibrant side.

Guys (and gals) I am trying really hard to get my hands on an encrypted device (preferably a Vibrant since I have all the files) to work on some solutions for post-error, but it is proving to be really hard bc either the user is pissed and borks the phone worse or they use the workaround in this OP and get it back running. I need to find someone who just said F**k It and got a new phone or is about to Upgrade/Re-Up their contract. I feel that if we can get a device working we can reverse engineer this somehow. We won't break the Encrytion Key but we could wipe it (if only it would mount-

and there it is

)

Sorry I haven't been around the past few days, but my tablet just got another update and of course, it will never please everyone and there is always something to trouble shoot. Just letting you know I am still on the case.
[Captivate Android Development] jonnyg1097:
So just a thought, if I were to call up Samsung and ask if they could repair my phone for me (which isnt under warrenty anymore) would they fix it if I told them that the phone isnt booting up properly anymore? Or would they just say that I am **** outta luck and then essentially have a paper weight on my desk.
[Captivate Android Development] melvinaury:
You know what, that's an excellent question. Just ask and then inform us.
[Captivate Android Development] swayjd:
Woodrube, as much as I would like to board the train and point fingers at MTP, the user I'm quoting just got it, and afaik cm9 has UMS by default for quite some time now. And while you may tell me that way back it might have been connected as MTP its just seems way farfetched that the problem would only surface 3 or 4 builds later. Quite saddened that Cyanogen himself acknowledged the problem and nothing changed, lost a bit of hope tbh.

They can fix it. the price at which they do it, might or might not be worth it though.

worse case scenario they replace the whole motherboard. And if, for whatever miracle, the price is acceptable you'll end up with a SAFE phone. since it APPEARS that no phone past 1010 build is affected.
[Captivate Android Development] RootTheMachine:
Hmm... I read the thread, and it sounded like the darkening that happens for the last few seconds in the boot animation, which is normal. BUT, if the phone got stuck when it's dark, I would find that very odd. Usually when my phone has somehow corrupted /data, it will never ever get to the point of dimming. It just sticks on the full brightness. I have also seen the dim boot animation after being rebooted from unstable OC settings, that's probably irrelevant though. So what does it mean when the phone is so close to being done booting, but it can't finish? Is the condition present already, or is this something that in turn causes it once the user reboots?

Additionally, it will probably take longer to fix a device that's already bricked than to create a preventative solution. Using ums may be one, but it doesn't seem to blanket every possible issue. I'm talking about modifying the boot sequence at the sacrifice of breaking encryption support entirely. Or at least making it more capable of dealing with this.

Sent from my CM9 i897 Captivate
[Captivate Android Development] lesterkravitz:
What would be the downside of doing the reverse fix on a fully operating phone? Just thinking if a phone would get the encryption the external would get encrypted and the internal would still be ok.
[Captivate Android Development] swayjd:
Got a lot of reports of people saying they can't install any apps. phone reboots. Don't know if it has anything to do with the quality of the emmc but its probably it.

Interesting nonetheless. Would like to know the answer as well.
[Captivate Android Development] lesterkravitz:
Just thinking until there is a fix this might prevent more broken phones, mine got the encryption 2 months ago with docs rom I did connect to computer the day before.
[Captivate Android Development] ReDaved:
usb storage sd card

I had gotten the Encryption Unsuccessful error, and was able to use the guide to make the phone usable, all worked fine.

So i flashed the latest nightly [4-27] and sd card is not showing up right in storage/camera not working. used the zip to flash the emmc sd card swap, and that is not working. when i go to settings storage, all looks fine for a moment, then it 'blinks' and i have what appears to be an unfilled sd card, camera does not work

also, google play -stops working- ?

any ideas?

thanks,
[Captivate Android Development] swayjd:
might have something to do with the new nightlies (started maybe 3 or 4 days ago) changing what used to be called sdcard to emmc. They did it standardize with other phones, that's what I understand anyway.

I suggest you try cm7 or an older cm9.
[Captivate Android Development] jonnyg1097:
Just a thought that I have, but if we were to to an intentional hard brick of the captivate and then get a jtag repair would that by any chance fix the problem or just leave us in a more terrible position?
[Captivate Android Development] jmtheiss:
It's possible it could be useful, but I see a few small hiccups with doing it:

1. How do we force the encryption unsuccessful error? I'm assuming you're thinking of trying Woodrube's method above.

2. Who will sacrifice a device to do this? If it doesn't work, someone is out a device that would otherwise resell for a decent price on the secondary market.
[Captivate Android Development] Red_81:
I think someone already sent their affected device to AdamOutler and he could not fix the issue through JTAG or the Unbrickable Mod.
[Captivate Android Development] visionlogic:
Does there exist a list of ICS ROM's which have MTP mode off by default? That is those that via build.prop and/or default.prop are defaulted to "mass_storage" mode (UMS) upon installation?
[Captivate Android Development] silvertag:
Most are Off but some have been already identified with the option set to ON. The best solution is to download the rom and

always flash unplugged

. Even if its set On you should have no problem turning it off and set it to UMS via the usual menus. After that you can plug it back in.

If the xxxxx.prop is set to MTP by default it will revert to it on the next boot

. Flashing unplugged is for testing and preventing the issue before it arise while you test out a new rom. This is not a permanent work around!!
[Captivate Android Development] Woody:
If what I have been reading is correct, the screen dimming is when the phone is just sitting there and not during the boot. Yosup said he just looked over and saw his screen was dimmer than usual and then Bam!! So it isn't that same type of dimming that you get 3/4 through the bootanimation just before you feel that little vibration kick. It is just dim while totally booted up already, just hangin out. That is why I am not sure if it means anything b/c most people don't have there phone out and the display on. I keep mine in my pocket or on my desk at work and since display eats battery, I usually have mine off when listing to music,...

Yep and he couldn't fix it. I know what JTag is and what it does, but have no idea how it works.

You can pull the build.props from the Raw ROM.zips. Not sure if you can do that with the default/prop though.

Red_81 and Vision: I dig your sigs.

Red->I like the Forum Rule #10 (Kind of why I log in somedays)

Vision-> The forethought that you are pre-warning people is good. The less we can have effected phones the better. Afterall these are investments as well as phones.

Agreed. Always err on the safe side. Since this popped up in January and I have been reading about people connecting (this was before the MTP theory materialized) I have been almost exclusive Dropbox on both mine and my wife's tablets and my phone. Better safe than sorry. Even Odin is a gamble for some reason too. Jsut b/c you PASS, doesn't always mean that it worked. Know what I mean.

YES the MTP link is still a theory and while I don't want it busted, the best way to prove it is to refute it. So maybe we can look at why we think this is NOT a viable option and therefore we can work backwards. I understand that we just want a fix, but we won't get that until we know what is broke. Follow me.

I'm still reading, but it's kind of hard to find stuff in the 10 million phones out there and not some blurb about encrypting emails or sms that has nothing to do with this.