Related
Hello, all,
I have recently taken an interest in developing Android 2.1 ROMs. So far, my work on 2.1 has been going well, except I cannot seem to get Android Market to install. I have tried re-signing the apk file, but the result is the same.
Can someone help me out on this? This has probably been answered before, but I cannot find anything truly relevant to this question. Any help is greatly appreciated.
someone needs to close this thread before this flame war gets any bigger
tekgek said:
Hello, all,
I have recently taken an interest in developing Android 2.1 ROMs. So far, my work on 2.1 has been going well, except I cannot seem to get Android Market to install. I have tried re-signing the apk file, but the result is the same.
Can someone help me out on this? This has probably been answered before, but I cannot find anything truly relevant to this question. Any help is greatly appreciated.
Click to expand...
Click to collapse
Have you tried just pushing with adb? By development do you mean cooking or compiling your own?
Please be respectful of others ...
I taken the time to cleanup this thread and move to Q&A where it should have been. If someone has an answer post a reply; plans to respond using trolling tactics are ill-advised.
If the thread goes OT again, a moderator will be forced to close it and likely remove it ... would be nice if it didn't have to come to that.
Regards,
I am building this directly from AOSP, from scratch. Thanks to the mod for cleaning up the flame war, by the way
Oh, from AOSP. How are you adding them in? AOSP does NOT include the Google Apps by default, I'm not expert in ROM building but I am sure there are some .libs needed (I know GTalk requires some) and possibly need the other Google Apps as well.
And this is why I love this place . What you said about libraries and what carz12 said about adb helped a lot.
Here is what I knew:
AOSP does not include the Google Apps, including the market. The market is somewhat difficult to install to an aosp build, and I think needs to be resigned with another RSA key.
What the forum helped me figure out:
The advice about trying the adb shell gave me some help. When I tried to push the market app to the phone, I got this:
./adb install alpha-1-signed/system/app/Vending.apk
898 KB/s (1274068 bytes in 1.384s)
pkg: /data/local/tmp/Vending.apk
Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]
Click to expand...
Click to collapse
This tells me that I am missing some libraries. But I'm also missing some other stuff. I'll recompile from source, install the libraries, and report back after I flash this to the phone. Until then, if anyone thinks any of my conclusions are wrong, please tell me so I don't waste my time, or yours.
EDIT: For all of you who are currently viewing this thread, how many of you would like a very fast (possibly faster than OpenEclair), stable, no-frills Android 2.1 ROM? I would like your opinions, because this will give me a good idea of how many people would be interested in this kind of thing.
Tekgek
tekgek said:
And this is why I love this place . What you said about libraries and what carz12 said about adb helped a lot.
Here is what I knew:
AOSP does not include the Google Apps, including the market. The market is somewhat difficult to install to an aosp build, and I think needs to be resigned with another RSA key.
What the forum helped me figure out:
The advice about trying the adb shell gave me some help. When I tried to push the market app to the phone, I got this:
This tells me that I am missing some libraries. But I'm also missing some other stuff. I'll recompile from source, install the libraries, and report back after I flash this to the phone. Until then, if anyone thinks any of my conclusions are wrong, please tell me so I don't waste my time, or yours.
Tekgek
Click to expand...
Click to collapse
It's good to know that you are missing libraries
Your best bet is to compile your rom, and then compare it to a rom that already has the google apps included (WesGarner build, CSDI, etc...) and see what libs are missing from yours, add them in and then try again
I was having the same problem too. I am gonna try this too.
And ya besides the libraries, the aosp build doesn't include some of the framework files and permission files too, like the framework files relating to gtalk and google maps should be added as well to the system/framework folder and the permission files in system/etc/permissions relating to gtalk and maps should be added as well.
I tried with all the missing libraries but with no luck...there must be some other files tooo. Gonna continue on Thursday.
Did you try resigning the apk file?
Not really. I am gonna try that too. Got coll tomorrow so may be later tomorrow. By the way did you got the video working?? I tried pushing some libraries from supereclair. But not workin till date. it works in his build though.
College is more important than android, imho. whenever you get the chance .
I hope to get video working in the future, but not right now. My primary computer (the core i7 rig I use for all my computer work) needed an OS reinstall, so I have made no progress since my post on ADB. My fist priority is to get the basics working, then I'll work on the other issues, like video playback and the camera. However, as of right now, I am re-downloading the source, and hopefully building it in the very near future, expect an update tomorrow, and maybe even a finished product (keep in mind that this is ALPHA, so don't expect anything wonderful).
Alright, I got it... mostly. The market appears installed, now all I need to do is make it not crash. Whenever I select the market app, I get a white screen, and then the home screen. I'm also getting a force close on the gapps process. What am I doing wrong
How did you got market show up???
The gapps framework file is also missin in the /system/framework folder in AOSP build.
Did you tried pushing the missing file?
I downloaded openeclair, pulled all the apps that had the word google in them, resigned the the market with another key, integrated them into a rom package, flashed, and voila, the market appears. I also added in a couple framework files, but I think I'm still missing something. Do you know what the name of the file is? I'm not sure what or where it is.
tekgek said:
I downloaded openeclair, pulled all the apps that had the word google in them, resigned the the market with another key, integrated them into a rom package, flashed, and voila, the market appears. I also added in a couple framework files, but I think I'm still missing something. Do you know what the name of the file is? I'm not sure what or where it is.
Click to expand...
Click to collapse
ya its com.google.android.gtalkservice.jar
okay, added it in, still getting a force close on the gapps. Where to go now???
As i mentioned earlier there are some files missing in system/etc/permissions. Did u tried pushing those files.
All permission files are in place, all gapps are resigned. The framework is in place. The setup wizard i also resigned, which now crashes. If anyone has any suggestions please post them. I am at my wit's end here.
this script is based on the work to Danesham90 and others see link
http://forum.xda-developers.com/showthread.php?t=598026
===============================================================================
Tested on the Samsung Vibrant, Script may need modification for other phones
===============================================================================
===============================================================================
Directions:
===============================================================================
the easy way:
1. turn on USB debugging
2. plug phone in to computer
3. run the script and follow the screen pormpts
the script will download everything needed to make a
signed deodexed clockwork flashable update.zip while also
adding root and the modified 3e recovery in the proccess.
===============================================================================
the hard way:
http://forum.xda-developers.com/showpost.php?p=10986893&postcount=28
================================================== =============================
Code:
/* This program is free software. It comes without any warranty, to
* the extent permitted by applicable law. You can redistribute it
* and/or modify it under the terms of the Do What The **** You Want
* To Public License, Version 2, as published by Sam Hocevar. See
* http://sam.zoy.org/wtfpl/COPYING for more details. */
UPDATED 02/03/2010
bug fix to signupdate.jar
clockwork script tweeks
UPDATED 02/02/2011
added upload to ROM to SDCard
added reboot recovery
added test sign all apk's in ROM - see README for details
added pull "/data/app/" and install "/data/app"
UPDATED 02/01/2011
added adb on by default toggle
added data wipe toggle
updated smali/baksmali to 1.2.6
UPDATED 01/31/2011
updated adb
fix similar filename deletion when using delete.txt
added barebones_delete.txt deletes everything that
does not cause phone to crash
UPDATED 01/29/2011
add "symlink dumpstate SYSTEM:bin/dumpmesg" to update-script.
add "symlink debuggerd SYSTEM:bin/csview" to update-script.
completed secondary method to make ROM from extracted Odin files.
see this post for instructions
http://forum.xda-developers.com/showpost.php?p=10986893&postcount=28
UPDATED 01/28/2011
added auto delete apk's (bloat removal), edit bin/example_delete.txt and rename to delete.txt
added auto add apk's (pre-install or update apk's) add apk's to bin/apks directory
UPDATED 01/23/2011
fix path error when space in user name
UPDATED 01/22/2011
updated TempRoot.exe to not trigger anti-virus
updated Superuser.apk
This is fantastic! Thank you for always making things a little less troublesome.
Oooops, last minute change broke something, fixed and re-uploaded.
untermensch said:
Oooops, last minute change broke something, fixed and re-uploaded.
Click to expand...
Click to collapse
Thanks for the heads up. I was just testing this on KA5 for funsies. It looked like it went ok but there was a prob with temp root at the beginning and it looked like a few java errors at the end. I'll re-download and give it another go.
Edit: Ah, looks like it's working now. Temp root worked and it downloaded the modem and kernel.
Edit2: So it looked as though everything worked fine, but when I went to install it I got
E:Can't symlink /system/bin/cat
E:Failure at line15:
symlink toolbox SYSTEM:bin/cat
Installation aborted.
Whitehawkx said:
Thanks for the heads up. I was just testing this on KA5 for funsies. It looked like it went ok but there was a prob with temp root at the beginning and it looked like a few java errors at the end. I'll re-download and give it another go.
Edit: Ah, looks like it's working now. Temp root worked and it downloaded the modem and kernel.
Click to expand...
Click to collapse
I just tested on my laptop and got a java out of memory error
while signing the rom so I increased the heap size which seems
to have fixed it.
untermensch said:
I just tested on my laptop and got a java out of memory error
while signing the rom so I increased the heap size which seems
to have fixed it.
Click to expand...
Click to collapse
Yea I got the same thing as well. Thanks again, will give it another go.
Update: The process was more in-depth when deodexing. Signing went through np and when I flashed through clockwork it worked (goodbye splash screen!). There must be some issue with KA5 though. It got through to the Galaxy S screen and then started vibrating and then blackscreen. T_T
Thank god for this.. (Deodexer)
Thanks untermensch, your the best
Really really appreciate this. Thanks a bunch!
Most useful tool EVAR!
I T W O R K E D~!
My final attempt last night did not shoot out the "signed_ROM.zip" at the end. I ran it again this morning on KA5 and when it finished I had the signed_ROM.zip in the folder. Put that on my internal, flashed through clockwork and viola! Doedexed KA5 with root and modded 3e recovery. I can't thank you enough Untermensch for putting this together for everyone.
"Give a man fish feed him for a day. Provide him with tools to fish and feed him for a lifetime." (Yea I tweaked it but you get the idea!)
I noticed one thing. During the deodexing process I got [null] on one file in the core.odex. After it had all finished up I looked in the framework folder and core.odex was still there. So am I correct in assuming that it did not doedex properly? Other than that everything else looks golden.
Oh this is sick. i was looking for this all day the otherday when i was trying to deodex ka5! you rock and rule. i cant wait to explore the possiblities!
Whitehawkx said:
I noticed one thing. During the deodexing process I got [null] on one file in the core.odex. After it had all finished up I looked in the framework folder and core.odex was still there. So am I correct in assuming that it did not doedex properly? Other than that everything else looks golden.
Click to expand...
Click to collapse
I deleted the core.odex file and rebooted just to see what would happen and it soft bricked and is stuck at the Vibrant screen. So it seems the only issue lies in deodexing the core.jar at this point.
can i use this to port a rom? forgive me if that is a noob question. just wanted to know if i had the right idea...
Whitehawkx said:
I noticed one thing. During the deodexing process I got [null] on one file in the core.odex. After it had all finished up I looked in the framework folder and core.odex was still there. So am I correct in assuming that it did not doedex properly? Other than that everything else looks golden.
Click to expand...
Click to collapse
yep that was an baksmali error, likely you could run the script again and it
would baksmali OK.
this script is a real system stress test, any way I increased the java maxmem
setting for framework files to 1024m added error logging and the script will
now stop if there is an error. hopefully to prevent a broken ROM from being
released.
Whitehawkx said:
I deleted the core.odex file and rebooted just to see what would happen and it soft bricked and is stuck at the Vibrant screen. So it seems the only issue lies in deodexing the core.jar at this point.
Click to expand...
Click to collapse
can you reproduce this error? I have seen it once but cant reproduce it
untermensch said:
yep that was an baksmali error, likely you could run the script again and it
would baksmali OK.
this script is a real system stress test, any way I increased the java maxmem
setting for framework files to 1024m added error logging and the script will
now stop if there is an error. hopefully to prevent a broken ROM from being
released.
Click to expand...
Click to collapse
untermensch said:
can you reproduce this error? I have seen it once but cant reproduce it
Click to expand...
Click to collapse
Pretty sure the core.odex [null] error I got happened every time I ran the program. I ran it once after the 1:25am update and it happened. That is also the time it did not produce the signed_ROM.zip. I ran it again this morning after I saw the OP had been updated and it did produce the signed_ROM.zip but I still got the [null] error on core.odex. I'm going to Odin KA5 and do it again right now. I will let you know how it works out.
On a side note. I flashed the one I recieved this morning with everything being deodexed except the core.jar and it ran great until I deleted the odex file. Anywho, will test now. Also, not sure if this matters but I am running 32-bit Windows 7.
Update1: Initial news is good. Core.jar was deodexed properly with no errors. Will let you know how the entire process fairs once its completed.
Worked perfectly. I got no errors and everything deodexed properly. Flashed it on my phone and it's running just fine. You are awesome.
Thanks for retesting, glad it worked, there are thousands of files being generated
an lots of java processes being spawned so there are bound to be an occasional
error. I have added an automatic retry when there is an error to the next version
should be posted some time tomorrow.
I'm about 3/4 the way through testing this out - it seems to be working just fine with the exception that every command is appended with "ATTRIB" is not recognized as...
Hopefully it will work anyway.
One thing I noticed that might speed the script up in the beginning would be a root check, I have already rooted this rom but it still needed to run rageagainstthecage.
I've been looking for something like this forever now, thanks so much! Can't wait to play with it.
Sent from my SGH-T959 using Tapatalk
I need help from you genius developers. I'm 99% done porting a rom over to release it here. I'm having issues with changing Phone.apk. I did the following:
1) Decompiled Phone.apk with apktool
2) Modified the manifest to add the permission I needed to add
3) Compiled it with apktool
4) Used 7zip to put my new manifest into the original apk
5) Used 7zip to put my new apk into the rom's zip
6) Flashed it and immediately after boot, got FC's on com.android.phone because it says the signature doesn't match the previously installed version and it will be ignored.
I found that if I place my modified Phone.apk on the sdcard, install the cpts binary (copies and retains the destination timestamp) in /system/xbin and set perms, I can do this:
Code:
adb remount
adb shell
# cpts /sdcard/Phone.apk /system/app/Phone.apk
I'll get this output and it'll work fine:
Code:
cpts /sdcard/Phone.apk /system/app/Phone.apk
Original ts:1290546488
Allocated 8388608 bytes.
But if I try to pull it from the phone, stick it back in the rom zip, it won't work when flashed clean.
I've beaten my head against the wall with this and any help will be appreciated.
TIA!
I think this needs to go in Q/A, since it's a question.
J/k. Have you tried Apk Manager 4.9? I've used it to mess with system apk's and data apk's, and it has options for both, which it handles differently.
PonsAsinorem said:
I think this needs to go in Q/A, since it's a question.
J/k. Have you tried Apk Manager 4.9? I've used it to mess with system apk's and data apk's, and it has options for both, which it handles differently.
Click to expand...
Click to collapse
LOL! I tried Apk Manager first and it wouldn't even decompile it without giving me errors.
I'll add some screenshots of what I've got so far. Maybe it will motivate someone to help!
Signatures aren't matching with what was previously installed.
Basically what you're doing is this:
Stock-Phone.apk has signature=1. (for example)
Your-Phone.apk has signature=2.
When you "hot-swap" them, it goes something like this:
Android: Hey, Stock-Phone.apk, what's your signature?
Stock-Phone.apk: It's numba 1, like me!
Android: Cool cool, *writes down. Go ahead and run!
*hot-swap here
Android: Hey, Your-Phone.apk! *looks at paper, ah, I have it written down! Your signature is 1, go ahead.
Your-Phone.apk: Hee hee!
Your-Phone.apk will use the cached signature to pretend like its signature=1.
However, putting it in a zip and flashing clean will not allow Android to cache any signatures. So Your-Phone.apk will read signature=2, and fail.
It'll go something like this:
Android: Hey, Your-Phone.apk, what's your signature?
Your-Phone.apk: 2!
Android: Sorry man, we only allow 1s in here, no execution for you!
Your-Phone.apk: FC FC FC FC FC!
I could never solve this problem without a two-zip flash and a full boot in-between, but some other devs might've managed to solve it.
PS I hope you enjoyed that analogy! xD
gmichaelow said:
Signatures aren't matching with what was previously installed.
Basically what you're doing is this:
Stock-Phone.apk has signature=1. (for example)
Your-Phone.apk has signature=2.
When you "hot-swap" them, it goes something like this:
Android: Hey, Stock-Phone.apk, what's your signature?
Stock-Phone.apk: It's numba 1, like me!
Android: Cool cool, *writes down. Go ahead and run!
*hot-swap here
Android: Hey, Your-Phone.apk! *looks at paper, ah, I have it written down! Your signature is 1, go ahead.
Your-Phone.apk: Hee hee!
Your-Phone.apk will use the cached signature to pretend like its signature=1.
However, putting it in a zip and flashing clean will not allow Android to cache any signatures. So Your-Phone.apk will read signature=2, and fail.
It'll go something like this:
Android: Hey, Your-Phone.apk, what's your signature?
Your-Phone.apk: 2!
Android: Sorry man, we only allow 1s in here, no execution for you!
Your-Phone.apk: FC FC FC FC FC!
I could never solve this problem without a two-zip flash and a full boot in-between, but some other devs might've managed to solve it.
PS I hope you enjoyed that analogy! xD
Click to expand...
Click to collapse
I DID enjoy the analogy! Thanks G! That makes perfect sense. I tried signing it myself with testsign.jar and it still didn't match the original. I may have to try the two-zip flash method.
have you tried playing with the one that inc does ported over?
the only thing that didnt work was wifi. if i remember correctly.
wes342 said:
have you tried playing with the one that inc does ported over?
the only thing that didnt work was wifi. if i remember correctly.
Click to expand...
Click to collapse
Thanks for the reply Wes. Yes, I tried using his Phone.apk file and it was missing the same permission. His port had more issues, like not being able to hang the phone up. So far, this is the last thing not working in my port.
Without this permission, when u get an incoming call, while the screen is off, the phone can't unlock the screen.
EDIT: And reading internal memory isn't working, but I'm not worried about that yet. It's 5:50am and time to go to work for me. I think I just needed some sleep as I spent too many hours on this last night. Today's a NEW day!
That's a pretty nice looking rom. Yea I gave you a bump because I like the lock screen.
Sent from my Incredible using XDA App
Gahh Its Lee said:
That's a pretty nice looking rom. Yea I gave you a bump because I like the lock screen.
Sent from my Incredible using XDA App
Click to expand...
Click to collapse
Thanks Gahh! It's real fluid at unlocking too.
No need to bump this anymore. I'm going to bite the bullet and set up a proper kitchen and see if it'll make this easier.
Thanks for all of the responses..
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my documentation on GitHub, which contains documentation and sample code to help you create FlashCast mods.
tchebb said:
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my flashcast-samples repository on GitHub, which contains documentation and sample code to help you create FlashCast mods.
Click to expand...
Click to collapse
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the jump drive, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
ddggttff3 said:
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the SD card, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
Click to expand...
Click to collapse
This would definitely be a useful feature. I can see a few implementation details that would need to be worked out in a non-obvious fashion, though:
There is currently no way for a imager script to directly access the root of the user partition. This is intended to prevent multiple scripts from having access to the same filesystem and possibly overwriting each others' files. Instead, scripts are executed in a temporary directory whose contents are discarded on device shutdown. It seems like the solution to this would be to create numbered backup directories, like there are numbered logs now, for mods to place their backups in.
It wouldn't be desirable for a mod to take a backup every time it was flashed, as not everyone cares about backups and they take up lots of space. There would need to be some way for the user to decide whether or not they wanted backups. Maybe another flag file?
Finally, taking a backup of an MTD partition using nanddump (dd should not be used to image NAND partitions, since it is not bad-block aware) images the entire partition, when (in the case of squashfs) only a small part actually has a filesystem on it. This means that a single rootfs backup will take up 400MB on the USB drive. I would want to implement something which can back up only the part of a partition which squashfs is using before I release backup functionality.
Obviously, this is a prime candidate for a new helper function, because of these non-trivial complications. I'll see if I can make the necessary changes to FlashCast and release backup functionality as part of v1.1. Thanks for the suggestion!
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
ddggttff3 said:
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
Click to expand...
Click to collapse
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
tchebb said:
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
Click to expand...
Click to collapse
Sounds great to me! Only other suggestion I have is to add another flag file which would allow Flashcast to continue flashing the multiple zips, even if one errors out.
So, by default if multiple zips are going to be flashed, and it errors on the first, it would stop, get a red LED, and then reboot.
with a flag file present, maybe ignore_errors, even if it errors out on the first zip, it would continue down the chain of zips until it finishes all of them.
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
tchebb said:
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
Click to expand...
Click to collapse
Im gonna dive into it
Have a little bug report.
If a person has more then 85~MB in their eureka_image folder, and then they start a SquashFS File system edit, flashcast will report an error saying out of space. Now, here is the error part. Even though it failed to mount with an error, the imager.sh file will continue to run, and will then attempt to flash back a corrupt file, causing a non-bootable chromecast until the system partition is re-flashed.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
The first script on THIS SITE will unpack the .PAK files, although it unpacks everything as a .png as it was made for a different Chromium device. So you would have to manually go rename all the files to their correct extension for the files, but because it expects everything to be a .png it won't pack back properly. The second script, technically should unpack/pack as proper file extensions, but I never got it to work right as I have little to no knowledge of Python.
The chromium source has a script,data_pack.py (which I can't link to since I'm a new user ATM) which can be used to pack and unpack .PAK files. The script posted above seems to be lifted from this source and modified to detect a few filetypes and write the unpacked files. But if you want to modify or add images and need to repack them, this script will help you figure it out. I'll work on adding and making some changes to the theme and give some instructions.
how to mount usb drive
Haven't used linux in years. Thanks!
Hey, want to do some poking around in the flashcast .bin file...how do I go about doing that? What is the file format, and is the image mountable in linux? Even better might be to extract files/folders from the image...what tool can I use to do that?
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
tomg09 said:
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
Click to expand...
Click to collapse
Buildroot does not let us build a bootloader, it lets us build a custom linux distribution that runs on the chromecast. The reason it is unable to do anything "graphical" minus the static image is due to licensing of the marvell GPU driver the chromecast uses. It is currently closed source, so it is unable to be compiled. We can use the blob from the stock OS, but ATM there is no need, and this can cause licensing issues.
Also, you can still access /dev and such on the stock OS. The big thing is the stock OS has usb input disabled at a kernel level, so it doesn't mount or detect any devices plugged in when the OS is running. This is circumvented though if you build and use your own custom kernel. For the features Eureka-ROM adds to the stock OS, we add those by using googles open source cross compiler for the device to build supported binaries.
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I havent found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
tomg09 said:
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I haven't found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
Click to expand...
Click to collapse
If we had a fully working open source graphics driver, lots could be accomplished. Full custom linux distributions could run x11 shells, we could have xbmc working with hardware decoding, and yes android would technically be possible if enough people wanted to put the time and effort into it. You can take the blob from the rom to do some of this, but things like hardware accelerated decoding will still not be possible due to the fact there is no documentation on how to use the blobs properly for things like that. (this is my understanding so I may be off on some small details, @tchebb can probably explain it more in depth.)
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
ddggttff3 said:
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
Click to expand...
Click to collapse
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
tomg09 said:
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
Click to expand...
Click to collapse
One more question...I've looked through the toolchain...the way it's set up is somewhat confusing. In the root directory of the toolchain: bin=gcc, g++, everything else I need to compile. What are the two folders entitled "arm-unknown-linux-gnueabi" and "target-arm-unknown-linux-gnueabi"? They seem to have relevant stuff (one has gcc, g++, etc except without the arm-unk... prefix, and other binaries which seem important). How do I use these/should I use these/why are they kept separate?
Thanks for the help.
I am in the process of building my first ROM/kernel for my Nexus 6 and I am very excited to run something I made myself. I have my build environment, SaberMod, etc all set up and ready to go, but I'm running into a few issues. I couldn't find a good guide for kernel building, so I'm using the one on Google's site here. I did the first sync in the guide and it said it was downloading 1.51GB, but when I looked in shamu-kernel I found one 7.3MB file! I shrugged it off and did the second sync in the guide. It uploaded 998MB, then downloaded 998MB., and when I looked in msm it was empty! I can't find these missing files anywhere.
My questions are:
1. Where did the rest of my files go from my first sync?
2. What was it uploading during the second sync?
3. Where did the 998MB it "downloaded" go?
4. My machine is running Fedora 22. Maybe Google doesn't like Fedora so they aren't letting me download anything?
Thanks,
Jeff
Face_Plant said:
I am in the process of building my first ROM/kernel for my Nexus 6 and I am very excited to run something I made myself. I have my build environment, SaberMod, etc all set up and ready to go, but I'm running into a few issues. I couldn't find a good guide for kernel building, so I'm using the one on Google's site here. I did the first sync in the guide and it said it was downloading 1.51GB, but when I looked in shamu-kernel I found one 7.3MB file! I shrugged it off and did the second sync in the guide. It uploaded 998MB, then downloaded 998MB., and when I looked in msm it was empty! I can't find these missing files anywhere.
My questions are:
1. Where did the rest of my files go from my first sync?
2. What was it uploading during the second sync?
3. Where did the 998MB it "downloaded" go?
4. My machine is running Fedora 22. Maybe Google doesn't like Fedora so they aren't letting me download anything?
Thanks,
Jeff
Click to expand...
Click to collapse
Hidden folder called .git in there. It's where all git data gets stored unless you have something checked out, though it should have checked out the default branch.
Make sure everything is up to date for your build environment.
Then to get the kernel source, just do:
git clone https://android.googlesource.com/kernel/msm.git
git checkout android-msm-shamu-3.10-marshmallow
You could always limit the git clone to just that branch to save space/bandwidth.
One you do that, all you need is to setup the couple environment variables arch/subarch/cc then make the shamu-defconfig.
I'm honestly not sure what sync you're talking about though in your post... Everything on that page is git clone... Nothing syncs.
Sent from my Nexus 6 using Tapatalk
Yoinx said:
Hidden folder called .git in there. It's where all git data gets stored unless you have something checked out, though it should have checked out the default branch.
Make sure everything is up to date for your build environment.
Then to get the kernel source, just do:
git clone https://android.googlesource.com/kernel/msm.git
git checkout android-msm-shamu-3.10-marshmallow
You could always limit the git clone to just that branch to save space/bandwidth.
One you do that, all you need is to setup the couple environment variables arch/subarch/cc then make the shamu-defconfig.
I'm honestly not sure what sync you're talking about though in your post... Everything on that page is git clone... Nothing syncs.
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Clone, sync, same difference. Thanks for the help! I'll work on it some more after class.
I have 2 final questions:
1. I'm trying to build a ROM that's prerooted, Busybox, init.d, all the usual basic stuff. Do I make those edits now before I compile it? Or do I build it, find it, unzip it, make my edits, then rezip it?
2. I have sort of the same question about the kernel. I want to disable forced encryption, the annoying corrupt boot message, and set SELinux to permissive. Do I make those edits now while it's still just a bunch of random files on my PC, or do I build it first then edit it like I mentioned in my first question?
Face_Plant said:
Clone, sync, same difference. Thanks for the help! I'll work on it some more after class.
I have 2 final questions:
1. I'm trying to build a ROM that's prerooted, Busybox, init.d, all the usual basic stuff. Do I make those edits now before I compile it? Or do I build it, find it, unzip it, make my edits, then rezip it?
2. I have sort of the same question about the kernel. I want to disable forced encryption, the annoying corrupt boot message, and set SELinux to permissive. Do I make those edits now while it's still just a bunch of random files on my PC, or do I build it first then edit it like I mentioned in my first question?
Click to expand...
Click to collapse
Clone and sync aren't the same... Clone is a one way pull, and exists in the git binary. Sync is bidirectional, if you have rights to modify the remote repo, and exists as a function of the repo tool. More or less...
You could do it either way, it's really up to you. Nothing you listed though really requires building from source. That stuff should all be able to be done by unpacking, modifying, and repacking existing Kernels/roms.
Sent from my Nexus 6 using Tapatalk
Yoinx said:
Clone and sync aren't the same... Clone is a one way pull, and exists in the git binary. Sync is bidirectional, if you have rights to modify the remote repo, and exists as a function of the repo tool. More or less...
You could do it either way, it's really up to you. Nothing you listed though really requires building from source. That stuff should all be able to be done by unpacking, modifying, and repacking existing Kernels/roms.
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
I see. I was under the impression that a sync and clone just downloaded something from a repository, so I stupidly assumed they were the same.
I want to build from source so I can say I've done it and just because I can. It's been a good learning experience so far and it's also pretty fun!
Thanks for the help!