Related
Someone who has done the whole DI01 update, please dump their system for me, or just the framework folder, apparently the one given to me had the stock android lockscreen patch applied to it lol.
Aside from that, the DI01 deodex works perfect, I opt_png'ed and zip_align'ed all the apk's, as well as the framework-res and twframework-res.
I will also need someone who knows how to sign updater-scripts to open the one attached, and just save it again properly and upload it for me. I am trying to get a flashable CW zip but the darn thing always gives me a status 6 error, which means the CW cannot read the updater script.
Sorry for the n00b question, but what benifit does deodexing provide? Also if there is another software update will I have to readd any .apk's to my /system folder?
Why not just flash your own system back to stock, then run the update, then dump /system? If you'd like an update script that doesn't update modem.bin, I already have one.
Assuming you're updating via CWM, why are you signing the zip? You don't need any signature, just zip the file up.
Is there anything involved in a dump besides just copying the files in /system?
namebrandon said:
Why not just flash your own system back to stock, then run the update, then dump /system? If you'd like an update script that doesn't update modem.bin, I already have one.
Assuming you're updating via CWM, why are you signing the zip? You don't need any signature, just zip the file up.
Click to expand...
Click to collapse
Because I am too lazy to go through all that.
I don't need it signed per say. More like opened, edited, and saved properly. It is said it is best to edit the update script in s Linux based environment which I don't have, but that notepad should suffice, yet when I save it with my notepad, I get the error of cw not being able to read it properly.
I have a fresh phone that just got the D101 update. Just need directions on what if anything is involved beyond just getting the /system directory via adb.
s44 said:
I have a fresh phone that just got the D101 update. Just need directions on what if anything is involved beyond just getting the /system directory via adb.
Click to expand...
Click to collapse
That is all I need. The only things I deodex are the contents of system/app and system/framework.
frostman89 said:
I don't need it signed per say. More like opened, edited, and saved properly. It is said it is best to edit the update script in s Linux based environment which I don't have, but that notepad should suffice, yet when I save it with my notepad, I get the error of cw not being able to read it properly.
Click to expand...
Click to collapse
Try a real editor, like bluefish or something.. Those scripts look like sh#! in notepad.
If no one has done it by tonight, just grab me on IRC and I'll do it under Linux for you.
Make sure you've got the file/directory structure right too.. You can't just throw a script in a zip file, but I'm sure you knew that. Myself and and a few others had the wrong directory structure at first, don't remember what error number that gave us though.. I think it just froze.
OK, how can I get it to you? I can't post links or (I think) files yet.
s44 said:
OK, how can I get it to you? I can't post links or (I think) files yet.
Click to expand...
Click to collapse
You can just zip it up and upload it to mediafire.com
Just splice up the link like WWW. Website. Com and I will just delete the spaces.
Mediafire upload just not working for some reason. Hm.
s44 said:
Mediafire upload just not working for some reason. Hm.
Click to expand...
Click to collapse
http://multiupload.com/
J1HDKEGYAR at multiupload
Used dsixdas Rom kitchen.
Built my own Rom using rogers stock RUU
starts to flash, then I get, error in sd card installation aborted
(status 0)
the last thing it was doing
minzip: extracted file "system/cuE:Error in /sdcard/marksrom
any takers??!!
Thanks guys
markdexter said:
Used dsixdas Rom kitchen.
Built my own Rom using rogers stock RUU
starts to flash, then I get, error in sd card installation aborted
(status 0)
the last thing it was doing
minzip: extracted file "system/cuE:Error in /sdcard/marksrom
any takers??!!
Thanks guys
Click to expand...
Click to collapse
What type of zip file is it?
its just the one that dsxidas tool spits out, although I did notice some differences.
If i click on the Rom.zip file, go to properties, then security. The only 2 that where check-marked was "modify" and "read & execute" So i compared that to a Rom that works on my device and noticed that in that same box they where all checked. - full control
modify
Read & execute
Read
Write
Special permissions
I changed those in my Rom so there all checked,however cant flash till tonight.
Just wondering if that could possibly be an, or the, issue
Not sure how to check what type of .zip file it is??
markdexter said:
Used dsixdas Rom kitchen.
Built my own Rom using rogers stock RUU
starts to flash, then I get, error in sd card installation aborted
(status 0)
the last thing it was doing
minzip: extracted file "system/cuE:Error in /sdcard/marksrom
any takers??!!
Thanks guys
Click to expand...
Click to collapse
markdexter said:
its just the one that dsxidas tool spits out, although I did notice some differences.
If i click on the Rom.zip file, go to properties, then security. The only 2 that where check-marked was "modify" and "read & execute" So i compared that to a Rom that works on my device and noticed that in that same box they where all checked. - full control
modify
Read & execute
Read
Write
Special permissions
I changed those in my Rom so there all checked,however cant flash till tonight.
Just wondering if that could possibly be an, or the, issue
Not sure how to check what type of .zip file it is??
Click to expand...
Click to collapse
Lol .. the "check boxes" you're referring to only indicate the access permissions for the specific .zip file. When in recovery mode, everything runs as root. If there is any read permission on the file, recovery should be able to acces it without any issues. Further, you mentioned above the recovery was in the process of flashing the file indicating the recovery has no issues accessing the file.
If the recovery has no issues accessing the file, there shouldn't be any issues with the specific permissions of the ROM .zip file on that specific file system in recovery mode.
As a ROM developer, the next step to troubleshooting and understanding errors when flashing a ROM is by becoming familiar with the custom recovery error log.
The custom recovery shows very limited information on the display, but in the log shows much more detail. The logs are generally kept at /tmp/recovery.log and /cache/recovery.log.
The best process is to process the .zip file and when the recovery errors, open up the recovery log. If you can paste back here the few lines before the error occurred including the error we can start working on the issue.
We might need a copy of the .zip file to match up with the recovery log to understand how much progress was made in order before the error occured.
The only other common place for ROM flashing errors when developing a ROM will be in the updater-script file. Might need a copy of this posted also.
In summary, the two most common places for issues occur either in the file name/structure of the .zip or in the updater-script.
Hope that helps! Good luck!
joeykrim said:
Lol .. the "check boxes" you're referring to only indicate the access permissions for the specific .zip file. When in recovery mode, everything runs as root. If there is any read permission on the file, recovery should be able to acces it without any issues. Further, you mentioned above the recovery was in the process of flashing the file indicating the recovery has no issues accessing the file.
If the recovery has no issues accessing the file, there shouldn't be any issues with the specific permissions of the ROM .zip file on that specific file system in recovery mode.
As a ROM developer, the next step to troubleshooting and understanding errors when flashing a ROM is by becoming familiar with the custom recovery error log.
The custom recovery shows very limited information on the display, but in the log shows much more detail. The logs are generally kept at /tmp/recovery.log and /cache/recovery.log.
The best process is to process the .zip file and when the recovery errors, open up the recovery log. If you can paste back here the few lines before the error occurred including the error we can start working on the issue.
We might need a copy of the .zip file to match up with the recovery log to understand how much progress was made in order before the error occured.
The only common place for ROM flashing errors when developing a ROM will be in the updater-script file. Might need a copy of this posted also.
In summary, the two most common places for issues occur either in the file name/structure of the .zip or in the updater-script.
Hope that helps! Good luck!
Click to expand...
Click to collapse
Amazing answer, thank you so much for taking your time with me, appreciate it, I'll try the recovery log, see what I get, as you can tell I'm pretty new to this, everyone has to start somewhere!
Thanks again buddy
Sent from my HTC EVO 3D X515a using xda premium
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Binary100100 said:
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Click to expand...
Click to collapse
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Keep me posted will ya?
I believe that Faux and other developers would have to use the zImage kernel flashing technique to get it to work with his existing app but I'm sure he can simplify it to accept .img files and the .ko files in the /system/lib directory of a zip file. It actually should be very easy. It took me about ten mintues with testing included to create the script for my method. I just can't code for apps else it would be done by now.
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
I contacted pershoot, no answer lol!!!
Joeykrim is willing to support the Amaze, he just needs testers, this would be a great backup incase the new script failed to push the kernel. I'll keep everyone posted with updates
Sent from my HTC Amaze 4G using XDA App
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Binary100100 said:
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Click to expand...
Click to collapse
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
seansk said:
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
Click to expand...
Click to collapse
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Binary100100 said:
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Click to expand...
Click to collapse
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
seansk said:
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
Click to expand...
Click to collapse
I'm sure there's a way to add a delay timer of some sort. I'm just not that savvy. Easiest way would be through an app like Tasker.
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
The short answer is yes!
I've setup the application to support the HTC Amaze 4G, but before I release it publically and officially, I want to have a few testers confirm everything is working properly for them.
Posted all the information in a new thread as this one seems to be covering a few different topics so I didn't want to "hijack".
http://forum.xda-developers.com/showthread.php?p=21574722
Thanks for the request and for reaching out to me DEFINITIONOFREAL.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
joeykrim said:
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
Click to expand...
Click to collapse
I look forward to tryin out your app.
It was basically what this thread was all about in the first place.
The clockwork method that you mentioned is the only workaround that I was able to come up with for custom kernels (like Faux123) because a kernel cannot be flashed through recovery without s-off. Really stupid. So I started thinking "How can we flash a boot.img file from recovery without the typical means?" Then came up with the solution to flash_image the boot.img file automatically IF the file is detected. But how to start a script automatically upon boot? init.d is the only way I could think of. Okay... so where to put the boot? I tried the sdcard but it failed to mount until it was way too late. So... data. Nope... still didn't mount in time. Cache? Well... how many developers will include a cache file into their roms? So the only other option was /system and it seemed convenient since /system mounts BEFORE the script can run (obviously) so that's why it is as it is. I also figured "If someone wants to flash a new kernel all they need to do is push the boot.img to /system and reboot." Must easier than using the EKF method (requiring PC access) and I don't know about you but I'm not around a computer 24/7.
Dear Admins,
Could we get a forum setup for the Cube U27GT WiFi version? I dug around on the site a bit beforehand but didn't see one, I apologize if I missed it and please direct me there if I did.
I have this tablet and I am doing some initial basic firmware development for it and want a proper place to start putting threads.
Dear Dev Community,
I can't root this bloody thing... At least, not the rom itself. Let me explain...
I can flash the stock rom from Cube and that can be rooted using Kango Root. --Fine...
However, I can't figure out how to replicate this when I make my own rom.
Thus far, here is what I have attempted...
1. Setup dsixda's excellent kitchen on my Ubuntu workstation.
2. Unpack the rom, clean things up, manually put the boot image into the dsixda unpacked working rom folder, run dsixda's root functionality (which add SU binary to xbin and SuperSu apk file to app folder as well as do some things with the boot image file).
3. Rather than using repack with Dsixda (which makes an update.zip image which I can't use because the stock recovery environment on this device can't flash zip update files and I can't for the life of me figure out how to get and or make a working CWM or TWRP recovery image for this unit)...
4. What I do is I run commands in linux to unpack the stock rom to another directory and mount that directory, then clear out a bunch of folders and then manually copy in my files from dsixda's working folder, then repackage up my unpacked stock rom into a new system.img file.
5. Then copy my now modified boot image, system image, and also userdata image (I modify that as well as that is where most all of the chinese bloatware is loaded from) to my SP_Flash_Tool, generate new checksum.ini file and flash normally...
What I get as a result...
1. As long as I am really careful with how I copy files into my new image, the new system flashes okay (if I am not careful, after flash USB storage for some reason has a format error and the system will boot but can't mount USB storage and other odd issues ensue as a result).
2. Assuming everything flashes okay, and no issue with USB storage partition, I have SuperSU installed and when I go to use an app (ES File Explorer or Root Checker) that require's root, I do get the prompt. However none of the root functions actually work and Root Checker tells me I am not rooted.
That is as far as I have got. So as a result, I have a really nice, westernized, cleaned up rom but with no root.
Anyone have any ideas?
This is my first adventure into mod'ing MTK roms so I am sure I am doing all kinds of things wrong . I had a good bit of experience on Rockchip SoC's before this though.
Kind regards and thanks in advance!
Roman
Figured it out!
So I finally did the following rather hackish work-around...
1. Flash stock firmware...
2. Root with Kingo Root
3. Enabled ADB
4. Attach to PC and fire up MTK Droid Tools
5. Take a full backup
6. Modify the system image from the backup and make changes
7. Put that in new firmware flash package
8. Flash new firmware
YAY - Cleaned up rom, modified, with root!
Once I get it all packaged up and uploaded to mtkfirmware.com I will post a link for anyone that wants a cleaned up rom with root!
The only downfall of the above method is that it absolutely requires that the developer have a device on hand because you can't just root the stock image file (at least, I couldn't figure out how... - bleh...
Kind Regards,
Roman
Dear roman,
Thanks for your hard work.
I have a simple question (I think) and if you have the time to reply or -any other android guru- I would be thankful.
My later issue was with a U27GT cube tablet, but I have others, one for each kid, and this is more of general question.
I am reading this and other forums about how to flash tablets from PC. My question is:
Can the flashing process be done from a SD card?
Thanks a lot and regards,
Fernando
SKorea
@superr
I'm having some trouble with ROM builds for the pixel XL. I made a bone stock ROM. It boots but has Bluetooth share force close. I think it's due to not being able to use sparse for perms. Currently trying with may build. I'm on Linux mint 18.1
toknitup420 said:
@superr
I'm having some trouble with ROM builds for the pixel XL. I made a bone stock ROM. It boots but has Bluetooth share force close. I think it's due to not being able to use sparse for perms. Currently trying with may build. I'm on Linux mint 18.1
Click to expand...
Click to collapse
It could be missing metadata. Are you starting with this fimware? I can unpack it and locate the files with unique permissions. It may help figure out what is missing. Not using sparse dat is not your issue. set_metadata will work once we track down the problem.
SuperR. said:
It could be missing metadata. Which firmware are you starting with? I can unpack it and locate the files with unique permissions. It may help figure out what is missing. Not using sparse dat is not your issue. set_metadata will work once we track down the problem.
Click to expand...
Click to collapse
Do you want a copy of the current project I have in kitchen. I can upload it to my drive. I just used the zip from the may factory image.
Edit
Wow I just realized that was a link lol. I totally misread lol. Yes I'm using that firmware.
toknitup420 said:
Do you want a copy of the current project I have in kitchen. I can upload it to my drive. I just used the zip from the may factory image.
Edit
Wow I just realized that was a link lol. I totally misread lol. Yes I'm using that firmware.
Click to expand...
Click to collapse
You did not misread, i changed it I will check it out when I get a chance. No need to upload your project.
toknitup420 said:
@superr
I'm having some trouble with ROM builds for the pixel XL. I made a bone stock ROM. It boots but has Bluetooth share force close. I think it's due to not being able to use sparse for perms. Currently trying with may build. I'm on Linux mint 18.1
Click to expand...
Click to collapse
Can you try this updater-script to see if it fixes the issue? There are actually 2 attached, with_vendor and no_vendor in case you extracted vendor too. If you replace it in the kitchen, make sure you zip the ROM manually because the kitchen will change it before zipping based on the files you have.
SuperR. said:
Can you try this updater-script to see if it fixes the issue? There are actually 2 attached, with_vendor and no_vendor in case you extracted vendor too. If you replace it in the kitchen, make sure you zip the ROM manually because the kitchen will change it before zipping based on the files you have.
Click to expand...
Click to collapse
so i cant zip manually because i dont have perms for one file in system. heres a pic. ill just add the script into an existing zip i built from kitchen.was
update
so i was able to move the script into the correct location and zip up the file. however when it flashes the updater script is somehow becoming merged with the original instead of just the new script. it still shows the original script text when flashing.
toknitup420 said:
so i cant zip manually because i dont have perms for one file in system. heres a pic. ill just add the script into an existing zip i built from kitchen.was
update
so i was able to move the script into the correct location and zip up the file. however when it flashes the updater script is somehow becoming merged with the original instead of just the new script. it still shows the original script text when flashing.
Click to expand...
Click to collapse
I will build a rom and upload for you to try. Are you building with vendor included or without?
SuperR. said:
I will build a rom and upload for you to try. Are you building with vendor included or without?
Click to expand...
Click to collapse
I built it without. Do you recommend to build it with vendor. Should that file be root like that. The one that's in that pic I sent.
toknitup420 said:
I built it without. Do you recommend to build it with vendor. Should that file be root like that. The one that's in that pic I sent.
Click to expand...
Click to collapse
Here is the marlin n2g47o test rom:
https://www.androidfilehost.com/?fid=817550096634774971
It is up to you about vendor. You must have matching vendor and system or the rom will not boot. If you inform users they must flash the corresponding vendor.img along with the rom you don't need to include it. The test rom does not include vendor so make sure you have the correct vendor flashed.
The root file you refer to is actually a directory symlink and should not be there at all. I have fixed this behavior locally and in this test rom. If all works, I will push the update.
SuperR. said:
Here is the marlin n2g47o test rom:
https://www.androidfilehost.com/?fid=817550096634774971
It is up to you about vendor. You must have matching vendor and system or the rom will not boot. If you inform users they must flash the corresponding vendor.img along with the rom you don't need to include it. The test rom does not include vendor so make sure you have the correct vendor flashed.
The root file you refer to is actually a directory symlink and should not be there at all. I have fixed this behavior locally and in this test rom. If all works, I will push the update.
Click to expand...
Click to collapse
OK I'll try it now. Good looks.
SuperR. said:
Here is the marlin n2g47o test rom:
https://www.androidfilehost.com/?fid=817550096634774971
It is up to you about vendor. You must have matching vendor and system or the rom will not boot. If you inform users they must flash the corresponding vendor.img along with the rom you don't need to include it. The test rom does not include vendor so make sure you have the correct vendor flashed.
The root file you refer to is actually a directory symlink and should not be there at all. I have fixed this behavior locally and in this test rom. If all works, I will push the update.
Click to expand...
Click to collapse
it flashes with no errors but it wont boot past splash screen.
toknitup420 said:
it flashes with no errors but it wont boot past splash screen.
Click to expand...
Click to collapse
Please try marlin n2g47o test rom 2:
https://www.androidfilehost.com/?fid=745425885120737663
SuperR. said:
Please try marlin n2g47o test rom 2:
https://www.androidfilehost.com/?fid=745425885120737663
Click to expand...
Click to collapse
flash went through without error but still boot looping at splash screen.
toknitup420 said:
flash went through without error but still boot looping at splash screen.
Click to expand...
Click to collapse
Moved to a dedicated thread as this issue is only about Pixel.
I will do more thinking on what could be causing it. I was pretty sure the last rom would fix it but clearly I was wrong lol
SuperR. said:
Moved to a dedicated thread as this issue is only about Pixel.
I will do more thinking on what could be causing it. I was pretty sure the last rom would fix it but clearly I was wrong lol
Click to expand...
Click to collapse
Lol good stuff. Keep me posted. I'll test whatever you throw at me.
toknitup420 said:
Lol good stuff. Keep me posted. I'll test whatever you throw at me.
Click to expand...
Click to collapse
Here is a new approach so I don't have to keep uploading full roms. Use the kitchen to extract the last rom I sent into a new project. In your file manager, navigate to your project directory and delete the 00_project_files directory. Extract the attached file into your project directory. Build rom with kitchen. Test rom.
Next time, you won't need to extract the rom zip again, just replace the 00_project_files directory.
edit: forgot to mention, after replacing the 00_project_files directory with the one in the zip, change perm types to something else, then back to set_metadata. Then build your rom
SuperR. said:
Here is a new approach so I don't have to keep uploading full roms. Use the kitchen to extract the last rom I sent into a new project. In your file manager, navigate to your project directory and delete the 00_project_files directory. Extract the attached file into your project directory. Build rom with kitchen. Test rom.
Next time, you won't need to extract the rom zip again, just replace the 00_project_files directory.
edit: forgot to mention, after replacing the 00_project_files directory with the one in the zip, change perm types to something else, then back to set_metadata. Then build your rom
Click to expand...
Click to collapse
flashing seemed to hang at setting perms. but it eventually went through. still looping at splash screen though.
toknitup420 said:
flashing seemed to hang at setting perms. but it eventually went through. still looping at splash screen though.
Click to expand...
Click to collapse
Can you send the original updater script that booted but did not have bluetooth?
SuperR. said:
Can you send the original updater script that booted but did not have bluetooth?
Click to expand...
Click to collapse
https://drive.google.com/file/d/0B4VEhClrJEWpNnJNVUJTRFV4ODQ/view?usp=sharing
https://drive.google.com/file/d/0B4VEhClrJEWpTmlYWC1CQ0s3LVE/view?usp=sharing
thats the binary and the script. i converted script to binary when i was building rom. this rom boots and runs ok other than bluetooth. its not completely stock though. i have my modded framework settings and system ui apks in there. but they are all signed so i dont think they would mess with anything.
toknitup420 said:
https://drive.google.com/file/d/0B4VEhClrJEWpNnJNVUJTRFV4ODQ/view?usp=sharing
https://drive.google.com/file/d/0B4VEhClrJEWpTmlYWC1CQ0s3LVE/view?usp=sharing
thats the binary and the script. i converted script to binary when i was building rom. this rom boots and runs ok other than bluetooth. its not completely stock though. i have my modded framework settings and system ui apks in there. but they are all signed so i dont think they would mess with anything.
Click to expand...
Click to collapse
Did you convert the new one you just tried after swapping 00_project_files to update-binary? If not, try it please. If so, try without please