[Q] Which phones to port from? - Droid Eris Android Development

I understand that we can only port from MDPI, but what about QVGA vs HVGA?
We should start a list of all the phones that can be used to port a rom to the Eris, and which ones are the hardest/easiest and what it takes to port them...
at least a list of phones would be nice

Hero
According to the thread about getting the Eris added to the CM team's tree, the Eris is very close to the Hero. But I don't know anything beyond that But hey, that's one phone for your list!

Here's my thoughts...
1) If you can build from source, do that. You have more opportunities to correct issues. You can't always correct issues by just swapping files.
2) Port from the CDMA Hero.
3) any of these phones should be fairly easy to port from, but some things may or may not work:
Hero (GSM)
Legend
MyTouch 3G (Sapphire)
G1
Wildfire
Aria
4) I don't generally mess with themes and converting densities and such, so I can't comment really on other phones. And if I remember right, some of those above are ldpi??? So, the icons were smaller, which was actually fine with me. I've done a lot of behind the scenes porting, but it's been a while. So, go easy on me.

The only phones i can ever port without error are the two Heros.... anything else and i get symlink problems while flashing.. im no dev, so i dont know how to figure this stuff out

Nikolai2.1 said:
The only phones i can ever port without error are the two Heros.... anything else and i get symlink problems while flashing.. im no dev, so i dont know how to figure this stuff out
Click to expand...
Click to collapse
Symlink errors are usually because the actual binary exists and you are trying to create a symlink for it. In my experience anyway... Just make sure the binary is there and if so, remove the offending line. Sometimes there will be enough that it just makes more sense to walk through the updater-script and check each symlink line.

gnarlyc said:
Symlink errors are usually because the actual binary exists and you are trying to create a symlink for it. In my experience anyway... Just make sure the binary is there and if so, remove the offending line. Sometimes there will be enough that it just makes more sense to walk through the updater-script and check each symlink line.
Click to expand...
Click to collapse
Well its usually when im just running the updatescript that came with the rom... should i try converting it to an updater-script? keep in mind im using the HTC rom kitchen, not the sdk lol

Nikolai2.1 said:
Well its usually when im just running the updatescript that came with the rom... should i try converting it to an updater-script? keep in mind im using the HTC rom kitchen, not the sdk lol
Click to expand...
Click to collapse
No need to convert it. I never did. I would just remove the symlink lines that are trying to create a symlink for a binary that is already there. Test again, and see if you still get the errors. I suspect that you won't. It might be that adding busybox has added these lines, but this particular ROM already has some of the binaries that busybox tries to replace. Or it might be something else. I couldn't really say without looking at the actual ROM you are trying to port.

gnarlyc said:
No need to convert it. I never did. I would just remove the symlink lines that are trying to create a symlink for a binary that is already there. Test again, and see if you still get the errors. I suspect that you won't. It might be that adding busybox has added these lines, but this particular ROM already has some of the binaries that busybox tries to replace. Or it might be something else. I couldn't really say without looking at the actual ROM you are trying to port.
Click to expand...
Click to collapse
Honestly its every few roms lol. im trying to port some legend roms and ill do those for a while and tell you what happens

well i tried legend and wildfire roms... i dont know what to do, for the life of me i cannot fix these update script errors.
First there was symlink problem with su, so i took it out
then theyre was a busybox line error, setting permissions i think, so i took it out
then it gave me a busybox install error, so i gave up then
any help would be greatly appreciated, im really gettting sick of being in the dark and not being able to do anything with a non hero rom

Related

Can we try EVO's new root method for 1.49?

Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
bowtieduece said:
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
Click to expand...
Click to collapse
Even though I didn't really think it would work, I gave it a shot anyway. Naturally, it was unsuccessful. The Eris take FOREVER to load that website, and it never triggers the shell script to ask for a reload, therefore permission is denied for the second part when you reboot with adb shell.
Interesting exploit, though. I wonder if there is some way to modify it for the Eris. Maybe you could contact the devs.
Really, nobody else is interested in this?
MyFixofAndroid said:
Yep that's what I expected. Yea there's gotta be someone here that can do the changes to the EVO files so they work with Eris, and upload the proper files to file sites and have us downloading in no time, so we can get root finally. Yes please anyone here up and willing
Click to expand...
Click to collapse
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
sickbox said:
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
Click to expand...
Click to collapse
Thanks for the tip. I sent him a PM. Will report back when I find something.
Anyone with an Eris can help out - rooted or unrooted.
I looked at those scripts last night - what seems like the necessary conditions for the beginning of the exploit (part1) are:
(1) there is a directory read/write/traversal permission security flaw in the data area for flash-lite;
(2) apparently, when flash-lite is running it must have root privilege at a moment when it performs a file "chmod" operation
So, an unprivileged user goes in, and makes a symlink (at the correct moment in time) in flash-lite's data area that points to a mtd partition - moments later, flash-lite "chmods" what it thinks is a file in it's data area, but instead, it is chmod'ing the target of a symlink - the normally protected mtd partition.
This allows use of flash_image to write whatever is wanted to that partition - even as an unprivileged user.
It should be easy enough for someone with Linux/Unix command line scripting experience to test to see if these conditions prevail on the Eris. You don't even need to be root - make your symlink point to something in /data/local if you are worried about something bad happening to a mtd partition. Chmod it initially to 600, and see if it get's changed by flash-lite when (and if) you drop the symlink into place.
I would do it, but I've got to go buy all the parts for ( & build) a new computer (no dev station as of last night ).
bftb0
bftb0 said:
Anyone with an Eris can help out - rooted or unrooted.
bftb0
Click to expand...
Click to collapse
Thank you for the detailed explanation. I'll have a look at the scripts, though it's more about learning new things for me, as this exceeds the current state of my unix knowledge. Hope others with more immediate knowledge of the subject will take a crack at it.
The shell script points to sharedobjects within /data/data/com.android.browser/flashlite, but sharedobjects, nor any folder for that matter, exists within that directory on the Eris. Is there a different place this could point; does the Eris have the same objects stored in a different location?
UPDATE: I'm searching my filesystem on my Eris right now to find it. I will report back later with results.
Also If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
MyFixofAndroid said:
Maybe the "sharedobjects" folder and other missing folders are really on the Eris, one of you should look for them. Use ASTRO or a different file manager and search most of the whole filesystem and see if you can find "sharedobjects" on your Erises.
In the meantime I'll try the same thing. Maybe there's a search engine for the file system of the Eris that you can get in the Android Market, that would do the trick. A file and/or folder search engine.
If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
Click to expand...
Click to collapse
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
I checked on my other Eris which is rooted. It seems that these may be the directories that we are looking for. However I don't find anything in an app-cache directory.
# find / -name *flashlite
find / -name *flashlite
/data/data/com.android.browser/flashlite
find: /proc/851: No such file or directory
# find / -name com.android.browser
find / -name com.android.browser
/data/data/com.android.browser
Well this appears to be the deal breaker then. Because non-root users of Eris cannot access /data as non-root, they cannot see anything in app-cache, and therefore cannot root yet, at least with this particular method unless there's another way to do it.
We should think of a way to still exploit Flash Lite on Eris, but use a different folder/folders in the Part? scripts that they point to for the operations of the script. This may be possible to do, however, still unlikely to work, and it is still going to be hard at this point.
But does anyone want to give my modified EVO method but for Eris a try? One of you should, so that we can root this thing and get it over with.
jimbonj said:
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
Click to expand...
Click to collapse
I dont think we would need read write permissions to begin with to use this root, if we had them to start we would be rooted
Because is he using a exploit in flash lite to write to a restricted folder, hes not just found a folder where the permissions aren't set correctly.
If flash lite can invoke admin access and we can exploit it there should be a way to root this.
I am going to the bar going to get some beers for my friends birthday, when I get home I am going to see if I can modify this into an eris root
Yeah JVWARD!
On your rooting effort, all the better, try modifying it for Eris and let all of us know if you succeed, hope you can, so we can get root too. Keep trying it with different changes until you get it to work.
Thanks.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
Click to expand...
Click to collapse
Yes sickbox, by all means, keep trying stuff, and finding that "flashlite" directory etc. till you get it to root. Hope your touchscreen returns to normal, and that you can create the directory that you mentioned in your previous post by using a flash site.
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
hey can someone with a rooted Eris using a an almost 100% stock Rom setup dump there file system and post it. Anyone using a highly customized Rom don't bother.
Sent from my Eris using Tapatalk
lostpilot28 said:
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
Click to expand...
Click to collapse
Link to the Evo instructions is in the OP. Currently working to see if it's possible on the Eris, so that's a no-go for now.
Stay tuned.
Team,
I've been working with the scripts with the awesome folks on IRC and have currently gotten thus far:
Part1 - http://pastebin.com/FUJWM3zW
Part2 - http://pastebin.com/6h07zrdm
I believe at this point I've screwed up my FlashLite plugin with my testing, so I'm going to try to recover that and keep moving along.
LR

{TOOL}MetaMorph Builder v3-Linux Only[8-5]

This could be considered part of the development forum or the apps and theme forum depending on how you look at it. if you have an issue, just click the report button and request that it be moved. no need to flame and troll and post that you reported it, just do it and move on.
Lots of people have asked me how to put together a theme control file, and its actually VERY easy but this tool makes it even easier.
this is an example of a theme control file created by this tool
Test-Theme.xml
Code:
<themename>Test-theme</themename>
<author>tater-salad</author>
<phone>Android Phone Codename Hulk</phone>
<rom>CM 8</rom>
<item>Phone.apk</item>
<path>/system/app<path>
<item>framework-res.apk</item>
<path>/system/framework</path>
<description>Requires reboot</description>
<item>FM-Reciever.apk</item>
<path>/data/app<path>
<item>My-custom-app.apk</item>
<path>/data/app<path>
run the mm-builder script and follow the on screen directions. you will of course need to put the correct replacement files in their respective directories, but this script will make all the right folders and set up your theme.xml for you. Bash scrip means linux only. This is also a super easy script, so i may get a batch version soon.
You can extract this file to any directory
All thanks to Stericson. W/O him we wouldnt have a metamorph app to begin with
######################################################################################################
v2
includes these additions
Code:
mkdir $app
mkdir $app/res
mkdir $app/res/drawable
mkdir $app/res/drawable-mdpi
mkdir $app/res/drawable-land-mdpi
mkdir $app/res/drawable-port-mdpi
these are the commonly used directories when it comes to theming. now all the sub-folders should be set up right.
I think this tool will be very helpful for newer themers and the like, looking forward to a windows adaptation.
also, what does it matter if ban_dover was andrizoid, seems to me hes not doing any harm here now, just trying to help people out, so give a guy a chance to rectify himself before you all start the flamethrowers
snyluc13 said:
I think this tool will be very helpful for newer themers and the like, looking forward to a windows adaptation.
also, what does it matter if ban_dover was andrizoid, seems to me hes not doing any harm here now, just trying to help people out, so give a guy a chance to rectify himself before you all start the flamethrowers
Click to expand...
Click to collapse
windows version is certainly viable, but batch is SO alien coming from bash. there isnt even an ls command
im going to have to play around and get a feel for batch before i get to work on it.
v3 is up. ive put together working metamorph themes using v3, so its been pretty well tested.
How about some constructive use of this thread?
ban_dover,
I've got a question. I read through Stericson's announcement post on XDA, and also the project page, and he mentions limitations due to signing checks of market apps.
Does it actually re-sign the .apk with the test key that all the devs use, or does it merely re-zip the .apk so that the manifest and keys are broken (won't pass a jarsigner -verify test)?
If it is the 2nd alternative, I guess that would means that Android does not check "non-market app" installs for valid signatures? Or that it doesn't check system apps but does check market apps?
The reason this piques my interest is that I noticed one of the devs recently released a ROM which had all its apps de-odexed and re-signed with the test key. (Can't remember which ROM, perhaps an xtr* ROM?)
Anyone else that knows how this goes is welcome to answer as well.
bftb0
Im going to lock this thread if the flame war doesn't stop
Play nice
Edit: Thread re-opened, ban_dover and I discussed and hopefully we will not have any more issues.
Thanks
Captainkrtek
bftb0 said:
How about some constructive use of this thread?
ban_dover,
I've got a question. I read through Stericson's announcement post on XDA, and also the project page, and he mentions limitations due to signing checks of market apps.
Does it actually re-sign the .apk with the test key that all the devs use, or does it merely re-zip the .apk so that the manifest and keys are broken (won't pass a jarsigner -verify test)?
If it is the 2nd alternative, I guess that would means that Android does not check "non-market app" installs for valid signatures? Or that it doesn't check system apps but does check market apps?
The reason this piques my interest is that I noticed one of the devs recently released a ROM which had all its apps de-odexed and re-signed with the test key. (Can't remember which ROM, perhaps an xtr* ROM?)
Anyone else that knows how this goes is welcome to answer as well.
bftb0
Click to expand...
Click to collapse
to be honest im not sure. but i can say that the rom your talking about isnt going to have any issues with anything because of the re-signing.
so the those who have downloaded it, what do you think?
ive tested it by putting together a few simple MMs, and it worked fne for me. have any of you ran into any issues?

[ROM] Deodexed rom with root

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

errors when using adb and CM6 on HTC aria

I wonder if other people are having these issues, story follows.
I was trying to install the updated ADW.launcher via the adb install command and was getting errors such as "/sbin/sh pm not found". This led to an investigation and it turns out that all the standard applications used to install stuff under android are in /system/bin BUT... The path in the CM6 rom does not have /system/bin in the PATH variable. The only path element as far as I can tell is /sbin. So the solution I came up with was to copy over all the tools from /system/bin to /sbin and this worked.
So here is the real question. How do I change the path on the android device? I have already tried export PATH=$PATH:/system/bin but this does not stick after I close the adb shell.
Update: oh great when you reboot the phone all the copied tools disappear and you have to do it all over again to install another file. Did not expect that one. This makes my need to change the path even more urgent.
Update2: I found it easier to just push the new file over top of the old one in /system/app. This will work for system apps and if I need to install other apps I can just load them from the sdcard.
Is there a reason you are not installing it from market? ADW is the default launcher in CM6, so the one from market is not the same, but they can coexist.
so the one from market is not the same, but they can coexist.
Click to expand...
Click to collapse
Yea I was not really sure about that so I felt it was safer to download the one for CM6. If that works I will do that in the future. I ended up just doing a push over the older version in /system/app, this worked fine.
Is there a reason this rom does not have /system/bin in its path? Is it to avoid toolbox?
anika200 said:
Yea I was not really sure about that so I felt it was safer to download the one for CM6. If that works I will do that in the future. I ended up just doing a push over the older version in /system/app, this worked fine.
Is there a reason this rom does not have /system/bin in its path? Is it to avoid toolbox?
Click to expand...
Click to collapse
It is in the path.
# echo $PATH
/sbin:/system/sbin:/system/bin:/system/xbin
#
Can you help me to change the path? Mine is only /sbin for some reason.
Normal export command did not work for me. Thanks
Maybe its baked into the boot.img? What about the init scripts? Any clues where to start? Maybe I will just flash on a new nightly, would that over write the existing path info?
Ok, I found some clues. A document on the android init scripts describes the path settings. I will poke around in there and see what I can muck up. http://www.netmite.com/android/mydroid/1.6/system/core/init/readme.txt
Sent from my Liberty using XDA App
Answered my own post.
To change the path you need to edit init.rc and add the correct path.
For some reason the nightly I was using had the wrong path in there and would not let me use adb install correctly. I would get an error back "/sbin pm not found". The adb installer was looking for a tiny program (a shell script really) named "pm" but it could not find it because pm is located in /system/bin which was not in the search path. Probably would have caused other problems too.
On a side note, why could I not get an answer to this simple question on a developement thread. Seems like rom creators/moders would know this second hand. Not complaining just makes me wonder.
Sounds a lot like a complaint to me.
I've been busy working on issues that are not isolated to a bad nightly, such as why we can't read telnos and contacts from the sim card.
/system/bin/sysinit gets pulled in from the cm6 repository, so things on nightlies are very fluid - I never know what to expect. Looking at my build, there is no way I could answer your question in any definitive way that would explain the discrepancy. Since I could not verify the problem, I deemed it a non-issue and moved on.
That did sound like a complaint, sorry. It was not really directed at you as I assume there is more than one developer on this site. I got it solved no problems. Maybe this will help someone else down the road. I have seen a few of these posts around and never saw a concrete answer.
I am surprised the phone ran so well with the path mangled so bad. I am also a little surprised that init.rc gets touched at all on a nightly cycle. One of those things I guess.
anika200 said:
I am also a little surprised that init.rc gets touched at all on a nightly cycle. One of those things I guess.
Click to expand...
Click to collapse
I was a little surprised as well.

[WINDOWS/ADB] (Busybox 1.19.4) Uncolored ls output! (compiled from source)

Hey!
I don't know if it has been posted before (and from what I can see in the "similar threads", it hasn't), but here it goes:
I've built, as my first ARM compilation, an uncolored ls output BusyBox (latest version, might I add) for you all .
Yes, I grew effin' tired of the whole garbage output when doing "ls" in busybox under Windows, and all of the solutions I saw in the interwebz (and XDA) were like, modify the CMD, use another command-line app (Console2 anyone?), put ANSI.SYS files on your path (Ewwww) and stuff like that. I had an out-of-the-box thought and said, hey, why don't I just fix the problem by recompiling busybox and setting --color as if it were --color=never.... always??
Well, I did, and here it goes. Enjoy.
It has been tested with my Nook Simple Touch, but YDMV (Your Device May Vary). I assume it could work in any, since I compiled it using codesourcery's ARM toolchain.
Take it easy on me though, I'm not very experienced in this ARM compiling stuff. If you guys are interested in the source, I'll post it. It's a small mod in coreutils/ls.c.
Enjoy
Hey, at least say thanks I wanna hear success stories and suggestions and stuff y'know! D: xD
can you make this flashable via cwm ?
I just figured out that I could replace the busybox link with one to toolbox to get rid of the color characters (ie. "ln /system/bin/toolbox /system/bin/ls) but I'll give this a try and if it works flawlessly, will include it in my ROM.
globula_neagra said:
can you make this flashable via cwm ?
Click to expand...
Click to collapse
Sure, give me this weekend to make a flashable update.zip file
Turge said:
I just figured out that I could replace the busybox link with one to toolbox to get rid of the color characters (ie. "ln /system/bin/toolbox /system/bin/ls) but I'll give this a try and if it works flawlessly, will include it in my ROM.
Click to expand...
Click to collapse
Hmm that's interesting, what does toolbox do in this case? is it somehow a stripped-down busybox of sorts?. Hehe, I'd love if you do use it though XD
Works on Micromax A70
Here is the flashable zip I made
Darkguy'sbusybox
If u get status 0 error while flashing then open the zip and go to this location
META-INF-->com-->google-->android and replace the update-binary with the one from any of your custom ROMs in same location
@darkguy2008
Good work
Add the flashable zip to OP
Thanks a lot mate! A very helpful contribution
Thanks buddy

Categories

Resources