See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
AndrewTL said:
See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
Click to expand...
Click to collapse
You need to go through all the lines of code for that and I believe some of them are binary files as well. Possible but will take much time. For now we must wait until someone finds a better solution.
Sent from my Kindle Fire using Tapatalk
signature issues.
6.2.1 experiment?
transfuntioner said:
signature issues.
Click to expand...
Click to collapse
Maybe I don't follow the process.. but I'm guessing no signatures..
not a signed bootloader.. no signatures required...
Get beyond compare and look at the differences between the OTA updates and the zip that Eldarerathis put together.
The ".bin" files are just ".zip" files renamed.
Look at
META-INF/com/google/android/updater-script in the bin files they release.
It is just a script.
And to do the things that it is doing, it has to be getting root permissions while it is running.
I don't know how to recover if it doesn't work, but I half wonder if you were to take the zip that fellow created, change the extension to ".bin" and just dump it into the update folder if the fire would install it for you?
He took out the image files from the script. He's just updating the system tree directly. He doesn't update the bootloader, recovery or backup trees.
For that matter if those contained something nasty, they could probably be pulled from an earlier update.
== cut ===
package_extract_file("recovery.img", "/dev/block/platform/mmci-omap-hs.1/by-name/recovery");
show_progress(0.100000, 10);
package_extract_file("u-boot.bin", "/dev/block/platform/mmci-omap-hs.1/by-name/bootloader");
format("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup");
mount("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup", "/backup");
package_extract_file("backup_userdata.zip", "/backup/backup_userdata.zip");
== cut ===
Please nobody try this idea that doesn't know enough to recover if it doesn't work, because I've not a clue how.
But could someone explain why wouldn't it work?
Worst case the rev might need to be manually edited to bump it one for the script.
Seems like it might be an easy way to get around headaches with OTA updates.
Andrew,
Are you having issues with getting into recovery so that you can test this? The Devolopers have a copy of TWRP 2 working perfectly on the device so you can get a clean backup of the OS before you test.
You sound like you may know what to do to fix the issue and I just want to help you get a good recovery in case it doesn't pan out or for testing.
~enjoy.
Actually I'm just afraid of messing up what I have working now.
I've got TWRP 2 running with the 6.2.1 image.
I'm setting these up as gifts. I spent a good 12 hours yesterday fighting the darn things. Guess I'm getting gun shy. Had a lot of issues with adb. Kudos to the new utility and setting the second ports up. I'm learning.
The OTA install wipes the system directory. It's in the script.
I was tempted to just comment that line out and see if it would leave the rest alone.
If I brick the thing its going to be painful for me to sort out.
I also didn't want to risk losing root. I also haven't tried loading an older OTA version.
At the time, I couldn't ask the fellow that developed the rooted 6.2.1 zip the question in his thread as I didn't have enough posts.
I'm going to be out of pocket for quite some time. I'm not going to have time to spend like this again for at least a few days.
But I was checking the zip he made versus the .bin/.zip files that the OTA releases using beyond compare. I wanted to see what files had actually changed.
That's when I found that script. It is manipulating permissions directly. It has to be running at a root level. I don't see anything like a signature on it, so why couldn't their own update system be used to tweak their own updates to allow for root?
Related
I've been searching XDA endlessly to answer this question or to point me in the right direction and have had no luck.
Basically, I know JF etc can modify the OTA updates so that they can keep root, but I can't find out how they actually go about doing it.
Since I'm a dev myself, I would like to have a crack at modding the updates. I know that JF created a modded recovery image signed with test keys so that you can update any update.zip signed with the same keys. (<- I'd quite like to know how this was done also). But it's the keeping root on update.zip that I want to know how to do and not just by using JF's build enviroments. Ie which files in update.zip need modifying etc....
Does that even make sense? Any help would be much appreciated or if anyone can point me in the right direction...
Many thanks
first you have to make a copy of sh and name it su and put it under /system/xbin
then you'll have to modify the update script buried in meta-inf and ask it to grant that su (and presumbly adbd) 4755 permission uid=0 gid=0
forgot this: resign...
Also need to unpack boot.img and change adb persist and secure.
bp8575 said:
I've been searching XDA endlessly to answer this question or to point me in the right direction and have had no luck.
Basically, I know JF etc can modify the OTA updates so that they can keep root, but I can't find out how they actually go about doing it.
Since I'm a dev myself, I would like to have a crack at modding the updates. I know that JF created a modded recovery image signed with test keys so that you can update any update.zip signed with the same keys. (<- I'd quite like to know how this was done also). But it's the keeping root on update.zip that I want to know how to do and not just by using JF's build enviroments. Ie which files in update.zip need modifying etc....
Does that even make sense? Any help would be much appreciated or if anyone can point me in the right direction...
Many thanks
Click to expand...
Click to collapse
Look in the init.rc startup script. You could probably setuid sh.
The truth is out there...
http://forum.xda-developers.com/showthread.php?t=518251
Thanks to anomalous3 over on the vibrant forum he was nice enough to port over his rom to our side based off of the new source code released by samsung
"If you feel like being a guinea pig, or know anyone who does, the deodexed build is here:
http://getyourboneon.com/CaptivateDeodexed.zip
Since I don't have a captivate I can't really test it, but it should work fine. It's based off that UCJH2 build. I didn't include any lag fixes since they've proliferated out of control, but I did include ext manipulation libraries and e2fsck to make life easier for people who want to use one of the lag fixes."
Please note I have NOT tested this rom yet, I don't have my captivate. Please somebody could test this and let us know if there's any problem so we can let him help us fix it.
Again, not responsible for whatever happens to your phone.
Here is the original thread I posted for reference.
http://forum.xda-developers.com/showthread.php?t=746466
EDIT: I'm going to assume you would install this like any other rom via update
EDIT2: anomalous3 has updated the link with corrections. Let us know how it works
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Zilch25 said:
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Click to expand...
Click to collapse
let us know how it goes
Do I just rename this to update.zip and go recovery and reinstall packages?
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Will do, flashing back to a stock JH2 while I download! I've been waiting for something like this
Clienterror said:
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
It probably was my fault anyway =P
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
damn it, wish this was around 2 hours ago when i was bored! its too late now to ruin my phone haha.. tomo sometime maybe i'll try..
Question...Do I have to install the stock Captivate ROM first as it states in the linked post? I have the stock ROM that is rooted with the AT&T bloatware removed. The only other mod is the lagfix version 2.3...Can I just flash this over that?
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
nammyczc said:
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
Click to expand...
Click to collapse
That's what's taking me so long... seems like JH2 is having some issues with update.zips... namely it's getting to the "Opening installer" then "Install Aborted". The(not new) update.zip for root still works, so I'm tossing on clockwork to see if I can get this thing crammed on here with that.
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Zilch25 said:
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Click to expand...
Click to collapse
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
BuglessPete said:
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
Click to expand...
Click to collapse
I'll pm him about this
nammyczc said:
I'll pm him about this
Click to expand...
Click to collapse
Also ask him why superuser.apk is in the xbin folder.
vietphunguyen said:
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
Click to expand...
Click to collapse
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
golemaw said:
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
Click to expand...
Click to collapse
This is correct. Deodexed ROMs can be themed...
BuglessPete said:
Also ask him why superuser.apk is in the xbin folder.
Click to expand...
Click to collapse
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
anomalous3 said:
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
Click to expand...
Click to collapse
updated original post with info
DISCLAIMER: These scripts have worked for me without issue. It would behoove you to ensure you have a solid back up to recover from in the event that something goes horribly wrong. These scripts should be considered a WIP. I will edit them and provide information as needed if something does not work as it should. Please feel free to post here or PM me if you have issues and bear with me if they do not work properly for you. END DISCLAIMER
To be honest, I am lazy. I flash CM nightlies and sometimes themes, and I didn't like having to navigate through recovery over and over again to wipe cache and dalvik-cache. So, I decided to write a script that would just do it for me. Then I got even lazier. I found that I had written several scripts and now I was tired of having to flash them all in a certain order. Which is why I wrote one all inclusive script.
Here I will provide you with two separate scripts. The first does just enough and the second does that much and a few more personal tweaks.
The first script is a rather simple one. It formats your /cache partition and deletes /data/dalvik-cache.
Wipe_Cache_Dalvik.zip
Edify version to work with Clockword Mod Recovery
1. Back up your current rom
2. Flash Wipe_Cache_Dalvik.zip
3. Flash your nightly/theme of choice
4. Reboot
The second script is where my personal preferences come into play. This script is meant to be flashed after you install your nightly rom. This script will format /cache, delete /data/davlik-cache, delete certain system apps that I do not personally use, and then copy an edited build.prop into /system so that the DPI is set to 190 immediately after you reboot from installing the nightly rom. This script will more than likely have to be changed to suit your needs. I understand that people will want different DPI settings and would like to retain the use of apps that I do not use.
Wipe_Delete_Copy.zip
1. Edit the script if you so choose. (Directions will be given in the second post)
2. Back up your current rom
3. Flash your nightly
4. Flash Wipe_Delete_Copy.zip
5. Reboot
Many thanks to Omegasun and his BareBone App and Sense Removal Plus Community Tools Thread.
This was the thread that got me started writing scripts. I learned a lot from him. My script would not have been possibl without his.
Many thanks to unCoRrUpTeD and his unCoRrUpTeD Dual Boot V1 Thread. I did a lot of testing for unCoRrUpTeD on his dualboot setup. I learned a lot from him in regard to using updater-scripts and updater-binaries. Without him I would not have been able to write the second script.
A thank you also to Calkulin for his format_all.zip which was another source of inspiration for the first wipe script.
As always a giant thanks to Cyanogen, Team Douche, TeamWin, and the Snap Team. The information and aid that they have provided to me is second to none. Without them I wouldn't know half of what I do now. Their contributions are what make this community great.
Any gratitude that you may feel towards me for these scripts should be directed towards those mentioned above. I wrote these to benefit myself and now feel that I should give them back to you all. I hope they work as described and make flashing a little bit easier on you.
These are rudimentary directions for the time being. I will edit and make them more precise later tonight. Also included a few things for reference. Like I said, it is basic info for now and it will become more detailed and informative.
You will need a text editor to edit any of these scripts. I primarily use Notepad++ on Windows. If you are on a *nix box then I am sure you are more than able to find a text editor that suits your needs.
1. Unzip Wipe_Delete_Copy.zip
2. Navigate to *\META-INF\com\google\android\
3. You will see two files: updater-script and update-binary
4. Open updater-script with your favorite text editor. (In my case, I right click and choose "Edit with Notepad++")
5. Edit Away
6. Save
7. Rezip
For reference, these are the files deleted from /system/app:
ADW Launcher
Browser
Car Home Google
CM Wallpapers
Development
DSP Manager
Email
FM
File Manager
Google Quick Search Box
Genie Widget (News and Weather)
Live Wallpapers
Live Wallpaper Picker
Pro Tips (The CM Widget that appears after a clean install)
Sound Recorder
VoiceDialer
Notice "ADW Launcher." This means you will need Launcher Pro/ADW EX/etc before you flash this. Or you will need to remove this line from the script.
If you don't want to change your DPI settings:
1. Open up the script in your text editor
2. Delete
Code:
ui_print("");
ui_print("");
ui_print("");
ui_print("Copying build.prop to retain proper dpi");
show_progress(0.200000, 5);
package_extract_dir("system", "/system");
3. Save
4. Delete the "system" folder found in the original zip
5. Rezip
This will be very handy. Thank you, sir.
+1 for this when I get to mess around with it after work tomorrow. Great job
swyped from my cyanogenized and gingerbreaded EVO
i have been thinking about making a cache/dalvik wipe script forever, but never got the will. thanks for making my life easier karadore.
I appreciate the thanks. I know the basic script will work just fine. It is very straight forward. The second one is kind of tricky because it uses an updater/binary. I just recently started working with them and had a few issues to begin with. The more feedback you all give me on this the better. Hope they help.
i dont know how to write in edify, but i would like to. if you dont mind whipping up a little tutorial, that would be fantastic so all the peoplez can stop complaining that they get an error after flashing my zips on cwm 3+. it would help me and a lot of others as well.
dkdude36 said:
i dont know how to write in edify, but i would like to. if you dont mind whipping up a little tutorial, that would be fantastic so all the peoplez can stop complaining that they get an error after flashing my zips on cwm 3+. it would help me and a lot of others as well.
Click to expand...
Click to collapse
I may just do that. Would give me a nice little project in the next few days to help me procrastinate from school and work a little more
Anyway to update these to work on CW 3+ recoveries?
sminker said:
Anyway to update these to work on CW 3+ recoveries?
Click to expand...
Click to collapse
The second script should work because it is written in edify. I will update the first one so that it works. Leaving for work now but I should be able to do it all from my phone. Will post up the new version in a few.
sminker said:
Anyway to update these to work on CW 3+ recoveries?
Click to expand...
Click to collapse
Just did a quick edit from my phone. This new zip should work on all CW Recoveries. Let me know if there are more issues. Will update the op once I am off work.
http://db.tt/sBi95OV
Karadorde said:
Just did a quick edit from my phone. This new zip should work on all CW Recoveries. Let me know if there are more issues. Will update the op once I am off work.
http://db.tt/sBi95OV
Click to expand...
Click to collapse
Awesome. Haven't tested yet but thanks for updating.
All I ask is that you let me know if it works or not. No reason why it shouldn't, but the more R&D the better.
are you still planning on giving an edify tutorial? and if not do you have any helpful pages or just all-telling .zips i can look at? thanks a bunch karadorde
Wait you flash first and then wipe caches? I've always done it the other way around. Does it even matter? Guess not...
Sent from my PC36100 using XDA App
matt2053 said:
Wait you flash first and then wipe caches? I've always done it the other way around. Does it even matter? Guess not...
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
You can do it either way. I always used to wipe and then flash.
The reason I am wiping after flashing the nightly is because of the other code in the second script. The second script deletes all of those system apps that I don't use and copies my edited build.prop back into /system. If I flashed the script before the nightly, then those system apps would be reinstalled and I would lose my edited build.prop.
dkdude36 said:
are you still planning on giving an edify tutorial? and if not do you have any helpful pages or just all-telling .zips i can look at? thanks a bunch karadorde
Click to expand...
Click to collapse
I have started putting together the thread. I will be adding to it today. I will dig up some other threads for you as well. Here is a link to the one I just started in Evo General.
http://forum.xda-developers.com/showthread.php?t=994940
nice work.. definitely helps me with flashing nightlies.. i would always have to go and remove most of that stuff.. the only thing i wanted to keep was DSP so i went and simply edited script..
works.
I don't think I have seen any mention of this idea yet. Sorry if I missed it...
In a recent thread about the 6.2.2 update and people wanting to prevent it, I thought I read that someone saw the file show up in the update directory. I'm assuming this means the same 'kindleupdates' directory you could manually drop the update into -- but if not, the idea is the same. Why not just take some step to prevent access to this directory?
The exact step to take would depend on how smart the developers were about dealing with problems in the update process
The easiest step would be to chmod 555 it. But of course if the update process is running as root it is under no requirement to honor those permissions! (My experience in the unix world tells me that about half the time, programs running as root do honor the permissions even though technically root overrides them).
Another easy step would be to delete it altogether. But they probably thought of that (if it's /mnt/sdcard/kindleupdates where someone could easily accidentally delete it) and recreate it if it's missing.
One trick that is often done is to replace the directory with a file. Some programmers do not think to check this kind of condition - they see there is something there, but they get an error opening it as a directory, and they just declare it's an error.
A more subtle trick would be to replace the directory with a symlink that points to a read-only directory (such as /system). In this case, they could open it as a directory, and just fail to write there. The programmer probably would not have thought to check whether it's a link vs. a real directory. One possible gotcha is if you point to /system, and /system is r/w, then the update could screw something up under /system. So maybe mount /system r/w, mkdir /system/kindleupdates, remount /system r/o, then link the update dir to /system/kindleupdates.
And finally, I don't know if Android has any kind of loopback filesystem capability, but loopback-mounting something read/only on that directory would certainly fake the OS into thinking there was a directory there; it would definitely be read/only, and I don't think they would ever think to check whether there is actually some filesystem mounted there! (and if there was, all you need is an app that constantly accesses some file you put there, which would make it busy so that it couldn't be unmounted).
The first method won't work because the sdcard partition is fat32 and doesn't accept unix permissions.
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
well, i just deregistered my kindle acount and i'm still in 6.2.1...
b63 said:
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
Click to expand...
Click to collapse
Ah, that makes this less practical. Still, perhaps when the next update comes out I can try a variation on this but it requires the filename to be known.
If the update is downloaded as a single file to /cache, which is named the same as the file you can manually grab, then someone who hasn't gotten 6.2.2 (and is not averse to this failing) can try this in a root shell:
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin/blah
The purpose here is to put something unremovable in the way of the file it wants to download. Most likely if the update sees something with the existing name there it would probably want to blow it away (after determining it's incomplete) - and since any update there would normally be a regular file, they probably would do nothing more complicated than a simple unlink syscall to delete it before re-downloading. However, since it's a directory with something in it, that unlink will fail. In actuality, making the subdirectory (second command above) should be unnecessary because the unlink should not work for directories; there's a special rmdir syscall for them.
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
Click to expand...
Click to collapse
I did read a lot of that last time and I don't think I actually saw a definitively successful method. If there is one it should be stickied
My interest in this is a little different from most of you guys - I have very limited satellite internet and I don't like these unscheduled 185-meg downloads so I want to be able to update only when I want mostly to control that. This kind of means looking for the least-intrusive way to accomplish this.
/cache/update-kindle-6.2.2_D01E_3205220.bin is exactly where it downloads
if you find a way to even prevent the download, that would be greatly appreciated
Unfortunately I already got the update so I can't try it this time.
at least you could try your method with a dummy file of an other name and try to overwrite it with adb - if you can't overwrite it there's a good chance
I think I'm about the only one who prevented 6.2.1. I did it by constantly checking the cache folder. Found the update by chance and deleted it before it updated. Waited over a week for it to come back. Never did. An app that watched the cache folder for the updates and then moved/deleted them would work fine
Sent from my SGH-I897 using xda premium
jcase already work a way around this automatic OTA update, so when FIREMOD is ready to replace burrito I think we will have no more problem with this OTA issue. (you can find jcase announcement in the kindle developer section)
Heres what I have done to prevent this.
1) Droidwall (white list only the apps you want to allow internet access)
2) Removed "otacerts.zip" from /system/etc/security/otacerts.zip.
3) I removed "OTASilentInstall.apk" /system/app
4) Installed this 6.2.2 based Rom http://forum.xda-developers.com/showthread.php?t=1439916
Hopefully this eliminates the OTA. I had my Fire rooted on 6.2.1 with twrp and it OTA'd on its own, broke root and twrp. So I rerooted with burritoroot2 and installed CWM based recovery.
I am attempting to apply an update of stock amazon 4.5.3 on apollo and there are three files being symlinked that are missing from my 3.2.3.2 device. Can anyone be so kind as to provide the following three files?
/data/misc/DxHDCP.cfg
/data/misc/audio/wcd9320_mad_audio.bin
/mnt/sqfs/fonts
The last one is a folder, so if someone could provide the folder and its contents recursively, that would be most helpful.
I don't have an Apollo so can't directly help with your request. However, I believe you need to be at 3.2.6 before upgrading to Sangria vs flashing a complete image. Maybe it's just those 3 files but could be others or different versions of identically named files. Smarter people in these forums can correct if I misspoke.
gbgadgets said:
I am attempting to apply an update of stock amazon 4.5.3 on apollo and there are three files being symlinked that are missing from my 3.2.3.2 device. Can anyone be so kind as to provide the following three files?
/data/misc/DxHDCP.cfg
/data/misc/audio/wcd9320_mad_audio.bin
/mnt/sqfs/fonts
The last one is a folder, so if someone could provide the folder and its contents recursively, that would be most helpful.
Click to expand...
Click to collapse
Did you manage to fix it using my tips?
p1gl3t said:
Did you manage to fix it using my tips?
Click to expand...
Click to collapse
I greatly appreciate the tips!! However, the time I have to mess with the device is quite random. I ended up having a problem restoring a backup and had to format the data, sdcard, etc partitions. I did have the backup also stored on a separate drive, so I got back up and running on a 'close to stock', rooted, xposed, gapps, etc 14.3.2.3.2 version. From there I went ahead and tried to update all but the bootoader to 14.3.2.6. This was successful and so I backed that up. Then I went ahead and re-tried the .zip you had posted for 14.4.5.2, and sure enough it flashed great. So, I am enjoying this fireos with unlocked bootloader, custom recovery, root, and gapps. I am sure I will try cm11, cm12, and aosp lolli as they come out, but for now, things are quite glorious with this device.
The devs around here (you included) are doing amazing things with this stuff. I really appreciate the teaching moments you guys (and gals) share too. What a great community.