Related
Alright, I've been using Fresh Toast for about two weeks now and love every second of it..The phone is incredibly responsive and everything I could want in a Hero. But I've run into a few problems/questions.
1. What does the option "Fix apk UID mismatches" option do in recovery? I've searched and it seems the only explanation is "it does just that" but I don't know what that is or means..
2. More often I've noticed I've had the mobile network not responding and had to toggle the option off/on for things like internet to work, but after the toggle it works just fine. It hasn't really started to be annoying till recently. Is this a problem in 2.1? Or Fresh Toast?
3. Possibly in conjunction, my phone has restarted 3 times by itself today..just sitting on the table. What could be the reason for this? I haven't installed or changed anything for at least a week, and it just started happening. It can get to be annoying because it takes a few minutes to boot up and a little inconvenient..
From what I understand, the apps and stuff have ID's which the phone can confuse sometimes, causing force closes of stuff you think should work. Fixing the mismatches helps with the force close problem some have. This is based off of knowledge I have gained from using th search button, but I am not rude enough to tell you to do a search when I am already typng you a message.
The random rebooting sounds like a problem you might want to take to sprint...
and I personally have been having some issues with mobile network using regawMOD lately... I am not blaming it on the ROM, jsut letting you know that I am using a different 2.1 ROM than you... mobile network locks up, doesn't respond and I have to toggle airplane mode to make it work, or it's just murderously slow compared to other times, andall while in the same location: my computer.
the random rebooting may be your phone unable to handle high frequencies... use overclock widget, and bring it down a notch to 710 or 691, and try that. The uid mismatches, I think, is a linux thing... the uid of a file is its permissions, aka read, write, execute, etc., but don't ask me how they get messed up and need that (you root your phone through adb? remember typing chmod 755 blah blah? the chmod command changes uid's, and the 755 is telling it what permissions to give it, but I don't remember the breakdown of the number, still learning linux myself)
Although the various Android boot screens are very colorful and exciting I was wondering if it was possible to display the processes being executed during boot instead of the boot animation. If so please post how in this thread!
the Android kernel does not report/print/output its loading status.
Are you sure? If you connect ADB Debugger during booting I can see ton of code whistle by, it's not the same as you'd get with linux install on a PC but could provide quite a nice alternative to boot animation Just need someone to redirect that output to the screen...
.FxN
That would require someone reworking 'ze code that handles boot animations to handle a live stream. Although crazy difficult, it would be awesome if possible.
Old school
The G1 would display a few seconds of code back in the JF ROM days when u went to boot into recovery. It was probably a random fluke occurrence on my end for not holding the home button long enough or something. At that time I was not to Android smart then, if i still had my G1 i would attempt to see if i could replicate it. I may still have some of his ROMs backup up on my server somewhere if someone wants to attempt to prove me wrong lol. I do agree with the OP it would be nice to have a live feed of the boot code instead of the animation.
kaotikking said:
The G1 would display a few seconds of code back in the JF ROM days when u went to boot into recovery. It was probably a random fluke occurrence on my end for not holding the home button long enough or something. At that time I was not to Android smart then, if i still had my G1 i would attempt to see if i could replicate it. I may still have some of his ROMs backup up on my server somewhere if someone wants to attempt to prove me wrong lol. I do agree with the OP it would be nice to have a live feed of the boot code instead of the animation.
Click to expand...
Click to collapse
That was actually just JF calling logcat as soon as it starts booting recovery and quitting when everything was fully loaded... :-(
That would probably be slow as hell... and if it wasn't, you'd never be able to read a single line.
There is a live wallpaper that does this, though. :O
Verbose boot would be pretty cool, in a geeky kinda way. Useless, but cool.
Whoa! My droid 3 just did something weird! I started getting screen artifacts that looked like a black terminal and it said something about a BP failure and BP bypass. This a pop up showed up asking if I want to switch to global mode since no cdma tower was available ( I switched to cdma only and it save crazy amounts of battery now). Then my phone rebooted without me making a selection! This has never happened before. I got to see this stuff, but I'm wondering if its cause I installed Log This that I was able to notice anything. What is (a) BP ?
If this is all software related, could the bypass get us escalated priviledges?
Darksurf said:
Whoa! My droid 3 just did something weird! I started getting screen artifacts that looked like a black terminal and it said something about a BP failure and BP bypass. This a pop up showed up asking if I want to switch to global mode since no cdma tower was available ( I switched to cdma only and it save crazy amounts of battery now). Then my phone rebooted without me making a selection! This has never happened before. I got to see this stuff, but I'm wondering if its cause I installed Log This that I was able to notice anything. What is (a) BP ?
If this is all software related, could the bypass get us escalated priviledges?
Click to expand...
Click to collapse
That's a bootloader protection (BP) Bypass. That may be the way in! Any way to replicate that? We need *FULL* disclosure on what was going on. A logcat output would be great!
Open ADB and type:
Code:
adb shell logcat > /sdcard/logcat.txt
adb pull /sdcard/logcat.txt C:\
Then upload that file (C:\logcat.txt) to a sharing site and let us rip it apart.
Some people over at phandroid had similar BP issues. There was no bypass message though. Maybe they are somehow related?
http://androidforums.com/motorola-droid-3/387878-my-d3-crashed-bp-panicked-error.html
forum.xda-developers.com/showthread.php?t=1188279
Yes, but we need the output of dmesg from before the panic. logcat will provide that.
BP=Baseband Processor=Radio
Something caused the radio to go into panic mode and it rebooted the phone.
This is not a way to get root unfortunately. The radio is setup such that in order to access it you need to bypass the AP (Applications Processor) layer where the OS and kernel etc. reside. That is what BP Bypass or Passthrough mode is for.
When you flash an SBF file the last stage of the flash re initializes the device for BP Passthrough to flash the radio partition.
The radio is literally a separate chipset on the board from the OMAP SoC and there are various access modes and device interfaces for all of those components.
Well bummer, I was hoping for something useful. At least we know that this has already been covered instead of wasting our time on it. Thanx for the info, knowledge is the key to everything.
either way, it'd still be nice to know what caused it.
Mine did the same thing shortly before it went to complete ****. After that happened it started rebooting itself all the time, rebooting itself coming back up with the welcome to android screen, even though there was no factory reset, it would reboot during calls, it would tell me i had missed calls from tomorrow. Browser barely functioned, apps would constantly force close. I brought it in to verizon after 3 days of it. Got a new one and traded my wife for her X. And now root comes. Ohh well i guess ill have to get by with a bionic.
pplude said:
either way, it'd still be nice to know what caused it.
Click to expand...
Click to collapse
I think it has something to do with not having CDMA signal. Just a guess. I have my phone set to CDMA only to save lots of battery, and sometimes all signal drops and then I get signal again (it happens when bouncing between 2 towers where I live) and then I guess the radio freaks.
I've only had it happen once, but I have notice that I had pretty good signal then bounced over to another tower and when I bounced back (all in a short time frame) is when it happened.
Just a guess.
Hey all just got this from a co worker as I revived a few others, but haven't seen this...any ideas?
UPDATE: got it fixed...the screen problem was from a corrupt NVRAM mmcblk0p12..It was missing tokens as well...first i ran tpdebrick-v004 to get it booted to this the crazy screen, then made a meta doctor that bypassed the token check by going into meta-doctor,and this is where it was hard to get things to complete how i wanted...from meta doctor wiki the commands are a tad off for our device and what i needed to do..using the link http://www.webos-internals.org/wiki/Sprint_Pre_Plus#Step_2:_Setup_meta-doctor as referance I cloned meta-doctor *but instead of putting the webos doctor 3.0.5 in the downloads folder i put in webosdoctor3.0.0 renamed to 3.0.5
1.Ran "make unpack" then went in and edited the recoverytool.config to remove the approvalbuildname,approvalcharliehash,and approvalmikehash.(i then edited the topaz.xml file in the webos folder to add tokens from another 32gb i had..(unknown consequences though)but should have worked without?.
THEN 2.Ran "make patch"
3.then ran "make DEVICE=touchpad CARRIER=wifi all" it will skip the make unpack and make patch commands and use your modified ones..these are the steps that seemed to be the differance for me and were not found..Maybe i shoulda known
4.membooted the device to rebuild the partitions(had to do this step multiple times as i was getting all the known errors)
5.Ran the modified webosdoctor from meta doctor and SUCCESS!!
And this was done multiple times til it all went smooth with no errors in one pass.*once the modified webosdoctor was made all i had to do was the tpdebrick and partition rebuild without error for the doctor to complete...sorry for the ramble....stoked
So maybe this can help someone else in the same spot as me.This was all done on ubuntu12.04 wubi
I had this on a touchpad once, never did get it working again.
I'm sure I read somewhere its down to a corruption in the gpu and is pretty bad news.
Would be interesting to hear if you manage to revive it...
Thanks for the reply...I can get it recognized as palm, and qhdload...holding power and volume up I can get the xp computer to see palm novacom bootie in device manager.. and can get webos doctor to start and it either hangs at 0%,8%,or 12% randomly..I know of those fixes but haven't been able to replicate them to do them yet... I also ran tpdebrick and have the info file from that showing a few errors...also ran acmeuninstaller and the screen went to the dual penguins, so that gives me some hope that it'll work... if it was the gpu would the screen work during that process? Any pointers or direction to be headed in let me know...I'll update with any progress...I feel it can be fixed...how can I access SD card thru terminal commands to see the dir.?
Sent from my cm_tenderloin using Tapatalk
Penguin screen from acmeuninstaller...still hope? And I can't get novaterm to connect...I could redo the lvm if I could connect to it...seems like that's where its stuck..thanks in advance..
Sent from my PG86100 using Tapatalk
Hm, seems like you're having a little more luck with yours than I did.
I did pretty much everything you've done and reached a dead end. Now it no longer has the weird screen, just black.
I haven't been able to communicate with it, through adb or novaterm, which seems like the best way to access dirs and internal file structure/partitioning.
Even running ubuntu on a usb stick I couldn't get in...
But you're right, there's cause for hope!
If u still have that TP leave it on the charger for a LONG time and that screen might pop back up...I only have about 30 mins to do stuff to it before its battery is too low again..after about 30 mins the screen just goes black(with backlight) but won't let novacom or novaterm connect until I charge again....
Well I got novaterm to connect...me being stupid forgot to go and hit connect haha..with that I was able to get [email protected] so went here http://forum.xda-developers.com/show thread hop?t=1426244 but the first lvm.static vgscan --ignorelockingfailure comes back with reading all volumes. May take a while... But stops instantly and back at [email protected] with the second lvm.static vgchange.-ay --ignorelockingfailure ...continuing on lvm.static vgcreate -s 8M store /dev/mmcblk0p. Comes back with not an existing volume, unable to add to /Dev/mmcblk0p to volume group"store"
So seeing that tried lvm.static pvcreate /dev/mmcblk0p 14 and got Device dev/mmcblk0p not found( or ignore by filtering) and Device 14 not found or ignored by filtering... Thought I'd keep it all up to date so if this can help me or anyone else ya know...I can get webosdoctor to 8% every time now but that's it..been trying the fixes listed but get stuck at fix_dos_sh.fs not found and the mkdosfs -f 1 -s 64 /dev/store/media comes back with something similar like the store not found.. Just an update
Sent from my PG86100 using Tapatalk
I do still have it, might just stick it on over the next few and see if I can't get somewhere with it.
Looks like you're on the right track anyways, just gotta find that magic formula.
I'll look through the resources I've used when doctoring in the past, see if there's anything I can throw at you but looks like you've got it all covered...
Keep it up!
Ya throw it on...who knows right I'll let ya know if I get it and could help...I just got it past all the lvm commands and everyrhing seemed to take fine..just didn't have enough battery to doctor yet....fingers crossed itll take n show a normal screen when it/if it finishes.
Sent from my PG86100 using Tapatalk
Ok, good luck with that.
Having used tpdebrick, did you look around the original tpdebrick v0.1 thread? Theres a useful discussion throughout, but I think somewhere around p25, but def somewhere between 20-30, there's more specific info about reading/writing partition info and getting a TP stuck in bootie mode to respond.
I tried using the dfu-util cmd mentioned in one post - there was other stuff about logs eetc - which resulted in a brief flash of the lcd - and my hope - but nothing after. Might be worth a look around if you haven't been there already....
Cheers, peace
Great thanks...I haven't read much on the v1 tpdebrick only the v4..I'll look at that today...
Sent from my PG86100 using Tapatalk
OK just an update...still the same, but narrowed it down to missing tokens in the NVRAM mmcblk0p12 block...running java - jar web doctor came back with tokens not found..should have been empty...I can bypass that with meta doctor and now stopping at 12% because of bad volume sizes...getting close I think...
But u were/are correct about the GPU..it is on the same block...I think it is only for the boot...so should be OK...
Sent from my PG86100 using Tapatalk
FIXED!!!! Reran tpdebrick, made meta-doctor to bypass token check as the nvram tokens were missing.. Then reset the partitions and ran the doctor...and success....I can say to ppl that there are a ton of minuet steps that will throw the whole process off if not done from start to finish perfectly...well we can see now that it is recoverable!!! Any help I can offer to anyone let me know here or pm......happy
Sent from my PG86100 using Tapatalk
Wow, amazing man!
I can't even get mine to the psychedleic screen now, just runs thru the tpdebrick process, says All Done!, then nada ...
Not sure I quite understand your first post, but will scrutinise it and see if I can take anything from it.
Well done again!
Peace
After unlocking the bootloader on each boot a message shows up with the message, that the device ist unlocked and cant' be trusted anymore. ist there any way to make this message disappear? (relocking the bootloader is no way! )
Same question exists in the OnePlus 3 section (with no solution)
Link to OnePlus 3 thread --> http://forum.xda-developers.com/oneplus-3/help/request-remove-bootloader-unlocked-t3405485
As far as I know there is no way to change it
It has been happening from OnePlus 3 and there is no way to remove it
but how can this be fixed on other devices? I've reat about some moto devices, where this message was "fixed".
Yes maybe someone will be able to do in near future
rUmtifUsel said:
but how can this be fixed on other devices? I've reat about some moto devices, where this message was "fixed".
Click to expand...
Click to collapse
I've already put up pretty much the similar post for the 3t not only here but also in the oneplus forums (3t), where I was actually contacted by a oneplus person asking for some details. I've fixed this on pretty much every single android phones I've ever had until now but this is clearly a new quirkier way of doing the logo that doesn't follow any tradition.
I'm guessing that it's been looked at by non-Oneplus people (here, other places) about a million times without finding where that partition, file, ramdisk, lives, and will stay that way until someone has incredible luck or intuition about it, or .. a oneplus engineer decides to reply to me (or you) and tell us the answer. They obviously know since they stuck it there to begin with. I've kind of hit the point where I just ignore it , push the on button (speeds by the screen) and go about my business. The only positive thing I've noted is that over on the oneplus forums, once someone at oneplus notices your post, you often get results, or at least, that's your best shot.
Cheers.
Hi there,
well, my guess that this is part of the IPL (Initial program loader; not boot.img) since the message appears pretty early in the boot-chain. It would make sence since it also checks the LOCK-status and decides if it allows booting unsigned boot.img images (which include kernel and ramdisk). The logic might look something like
if (bootloader.isUnlocked()) {
showMessage();
bootUnsignedImage();
} else {
bootSignedImage();
}
rUmtifUsel said:
but how can this be fixed on other devices? I've reat about some moto devices, where this message was "fixed".
Click to expand...
Click to collapse
This is a standard on Nexus devices and isn't "fixed" on them. Doubt it's going to be different on this.
http://www.droidforums.net/threads/bootloader-unlocked-warning-cant-be-removed-on-nexus-6p.286627/
Pretty sure it's a standard in all new Android phones, and really doubt it will ever be removed.
gladiac said:
Hi there,
well, my guess that this is part of the IPL (Initial program loader; not boot.img) since the message appears pretty early in the boot-chain. It would make sence since it also checks the LOCK-status and decides if it allows booting unsigned boot.img images (which include kernel and ramdisk). The logic might look something like
if (bootloader.isUnlocked()) {
showMessage();
bootUnsignedImage();
} else {
bootSignedImage();
}
Click to expand...
Click to collapse
I think that's somewhere near the truth. I've got build-able source for the 3t (3.5.3) and just finished getting the prebuilts from the phone as well, so here goes a most-likely fruitless search for something resembling a clause that I can figure out where the actual screen is coming from. If I can string together a well enough constructed $find | $grep -i {whatever} | {as many other cmds as needed}, then when I get back from work today, I can find out (well, probably) nothing at all , but it's worth a shot since I don't have to watch it and wait.. ;
gladiac said:
Hi there,
well, my guess that this is part of the IPL (Initial program loader; not boot.img) since the message appears pretty early in the boot-chain. It would make sence since it also checks the LOCK-status and decides if it allows booting unsigned boot.img images (which include kernel and ramdisk). The logic might look something like
if (bootloader.isUnlocked()) {
showMessage();
bootUnsignedImage();
} else {
bootSignedImage();
}
Click to expand...
Click to collapse
I found this code in the file listed after the code:
Code:
#if FBCON_DISPLAY_MSG
display_bootverify_menu_thread(DISPLAY_MENU_ORANGE);
wait_for_users_action();
#else
dprintf(CRITICAL,
"Your device has been unlocked and can't be trusted.\nWait for 5 seconds before proceeding\n");
mdelay(5000);
#endif
}
#endif
Filename in build tree: ~/sandbox/oneplus3t/bootable/bootloader/lk/app/aboot/aboot.c
------------------
So:: There's quite a bit more text for that screen in that file, and it's not as simple as just replacing the entire file with a single line that (e.g.) sets a = 0;
The thing is that the file does a lot of checks and I suspect the boot process won't even get it's feet wet if the file is actually damaged, but ::
The code above could pretty easily just be slightly modified not to print a message or to print a nice message, or a pretty little graphic, and the delay has no reason to exist. As soon as I can get 3.5.3 to built without errors (I just downloaded it again since my first try was from a 3rd party git repo), I'll see if it can be tampered with. The real problem is "Is this worth screwing around with?" . How many people (and I'm not even one of them) would want to blow away their setups just to install a new OS that has this crazy change in it.
Anyway, now that I've found it, I'll see if I can find some better way to handle it, but many have fallen on this sword so I probably will follow in their footsteps.
edit: As I was staring at the filename, it dawned on me that it's where all the stock & custom recoveries are made and is the next tree over called bootloader. That "might" (really doubt it) make this more doable. If we only had to change one partition to get rid of this thing, it'd be more like flashing a logo partition to get rid of it. My guess is that they're way to smart to allow someone to slap a different bootloader in there without there being a price to pay. (like no longer booting because of dm-v*). We'll see.
If it ain't broke
don't fix it
obamadictator said:
If it ain't broke
don't fix it
Click to expand...
Click to collapse
What're you? An insurgent? lol. This is XDA, the home of breaking things that ain't broke. ;
OK, the way I see it is that this problem is pretty much the same everywhere. What differ is the type of message it convey. To me and maybe the initial poster as well is not that it have some sort of language saying it's unlock, but it also has 5-sec delay which is annoying. In my opinion, say a Nexus device which only show a picture of a padlock "unlocked" is a much nicer way to me. That said, that little padlock may not enough to tell a normal person looking at a phone and for them to know it's boot-loader unlocked and it could have "extra stuff" hiding in the system. Originally Nexus and OP device serve different market. OP were aim at the mass, the normal people, while Nexus served the dev. So if we start with that point, then it make more sense that the OP device bootloader unlocked message need to be more clear. Even though it's annoying, but it's a phone to me and I intend to have a stable ROMs on it and I don't have a need for it to reboot every day or many time a day on the normal usage. So, if I'm not going to see that majority of the time, I'm ok with that. If it need to be fixed, I think at least the language on the message could be better, and maybe tell us what is going to load after the 5-sec delay, eg: system or recovery.
To clear things up:
The security warning is displayed by what lives in the aboot partition. It is a part of the boot chain and the piece that loads the kernel. Each part of the boot chain verifies the next one using RSA certs and signatures, starting at the bootrom, which is read-only. Aboot is also responsible for fastboot, the splash screen, and everything else you see on your device which is not recovery or OS (except hsusb 9008 mode, which kicks in in case the cert chain described above fails). Whilst some part of it source code may be included in the OOS device tree all magic is left out. The partition itself contains an somewhat corrupted elf file you could analyze. (If you do, remove the two "NULL" and the "EDIDX" program header). Maybe some qfuse or toggled bit somewhere can remove the warning. If you are good at reverse-engineering low-level arm and know some quallcomm internal stuff, go ahead. Otherwise, please stop confusing things and repeating things that are wrong or irritating.
justibasa said:
This is a standard on Nexus devices and isn't "fixed" on them. Doubt it's going to be different on this.
http://www.droidforums.net/threads/bootloader-unlocked-warning-cant-be-removed-on-nexus-6p.286627/
Pretty sure it's a standard in all new Android phones, and really doubt it will ever be removed.
Click to expand...
Click to collapse
it's fixed on nexus 5x
https://forum.xda-developers.com/showthread.php?p=70567187
What's the variable "FBCON_DISPLAY_MSG" set to?
If the code is written in c (which from the looks of it; it is)
Couldn't you just set a global variable = to whatever the default value is? Or for example if something is changing that value when you unlock the bootloader, just set it back to default after that.
If it's in the aboot.c file, then it must be part of the boot.img right?
Also the boot.img file isn't the whole OS. As long as you don't tamper with the actual calling functions for the system it should be fine "theoretically". My OP3T should be coming in tomorrow, so maybe I can take a look at this as well when I have some time.
EDIT: I just read Jo_Jo_2000's response after what I wrote. That actually makes sense, and that's probably what makes this more difficult to do because you have to re-sign the files using valid certs, otherwise if it fails who knows what could happen since you're modifying the boot partition
any update on this issue?
As I understand the problem there really isn't a way to "fix" it that doesn't involve disabling more security. the dm-verity feature is built in and verifies that the boot process hasn't been tampered with. Once you unlock the bootloader, that isn't the case and dm-verity will always alert. Until you reflash a completely stock "factory" setup and re-lock it in that state. There could be some minor differences necessary to make this happen, but the gist of it should be correct.
I'm hoping against all odds that this isn't the case and that someone will eventually figure out how to re-enable dm-verity for a specific build... such as OOS_Beta + Magisk. But I'm pretty sure that's a futile hope. Google's been waging war on root for a while now and they're winning. Since they ultimately control the platform, it's my prediction that they're going to win.
This wouldn't bother me so much if I thought the ad networks were malware-free. I shouldn't have to expose my personal data or security for advertising. I don't care how passionately you argue on behalf of the content creators.
You really can't without someone customizing their own boot.img with that out. Even then you will see a black screen for a second before it advances to actually boot. Once the bootloader has been modified in any way, this trips and tells you basically you cannot use safetynet stuff. Its not a big deal, OnePlus 3t allows you to skip it pretty quick. Unlike my last phone i had to look at that screen for the entire 5 seconds it asked me too even if i asked it to boot immediately. Its just a warranty and security thing its not a big deal. Can be ignored just like the dm verity warning. Trust me, you dont have it as bad. I get both the bootloader and dm verity warning in the same boot. I do actually enjoy them though because they let you use the volume up and down option to go to fastboot or bootloader or recovery or just turn the thing off without needing to do the stupid button presses which i never remember which one does what. Theyre a nice blessing on this phone i must say. a few vol down clicks and im in twrp. Its nice.
In the oneplus 5 has been done!
https://forum.xda-developers.com/oneplus-5/themes/mod-bootloader-changer-t3800862