• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [ROM] Jiilik's custom Shine Plus ROM's

I really appreciate all the work you're doing with this phone, jiilik.
I have a question, though. You said earlier in this thread that the cpu runs at a default of 480 Mhz, yet I'm running the stock 2.3 rom and android system info tells me that it's running at 600 Mhz.
Oh, and would it be possible to rollback/put in the drivers for the auto-brightness sensor from 2.1 so that that feature works again in 2.3?

It was 480 for one of his first kernels, it defaults at 604 now.

Sadly it's not a driver, but embedded code in the services.jar. The reason they deactivated it is probably because of the black screen issue (Which it did not solve), just goes to show LG is not knowledgeable with Android. I'm actually working on something, but I'd have to decompile settings.apk and add the auto brightness option, just not sure how the phone will react. It's not that easy to backport from 2.1 as the entire code structure changed from Eclair to Gingerbread.
 
Jiilik, another suggestion for your ROM, remove stock launchers, they take up 10 megs. Install zeam launcher as a backup solution. ;) Gives you more overhead to work on system partition.

And by the way, confirmed... It is Dalvik cache causing an issue. All apps start crashing everytime you restart the phone. I'm investigating right now what can be done. Either put an init.d script that wipes dalvik on boot and rebuilds or either try and figure out why app2sd screws up dalvik. Might be the symlink... Dalvik is in cache/Dalvik-cache by default while it symlinks it to data/dalvik-cache when the script runs. Will keep you posted.
 
Jiilik, I think something might be wrong with the base. I started playing around with the system partition because it was low in space for some odd reason. I moved a bunch of random apps to user apps (Facebook, gmail, maps, etc.) and suddenly I went from 2mb free to 69! I think because system partition is low in space, whenever it attempts to reboot, it writes to it and then stalls because it runs out of space.

I also seem to have failed for the CRT off animation, sadly. Oh well. ;) Next time I'm free...

OC'ed the phone to 768 by the way with ondemand governor and I'm able to play Angry Birds without crashing with 008.

Will keep you posted on screen freezes.
 
Will do right now. I actually have a nandroid that can reproduce the issue everytime. ;)

also, another Amon RA problem: It says it backs up sd-ext (Ext3 partition) but it does not. So if you symlink to sd-ext, it will not restore your apps, only data partition... Not sure if flashing CWM would fix that.

Did you try CWM? As in boot in it? I don't want to mess up my recovery right now. ;) haha

Yeah - it boots, backs up, restores, and flashes roms fairly well. Haven't tried some of the other features.
 
Jiilik, I think something might be wrong with the base. I started playing around with the system partition because it was low in space for some odd reason. I moved a bunch of random apps to user apps (Facebook, gmail, maps, etc.) and suddenly I went from 2mb free to 69! I think because system partition is low in space, whenever it attempts to reboot, it writes to it and then stalls because it runs out of space.

I also seem to have failed for the CRT off animation, sadly. Oh well. ;) Next time I'm free...

OC'ed the phone to 768 by the way with ondemand governor and I'm able to play Angry Birds without crashing with 008.

Will keep you posted on screen freezes.

Hey, well that's good news. I haven't actually tried Angry Birds on 008. All my testing was on 007 before I added AVS to the build.

Also, I haven't had any real issues with the size of system. But removing facebook/gmail/youtube is probably a good idea anyway, since they are all available on the market anyway.

I won't have time to do much work on this for the next few days. Real life. Anyway, hope your hacking yields dividends! :D
 
Hey, well that's good news. I haven't actually tried Angry Birds on 008. All my testing was on 007 before I added AVS to the build.

Also, I haven't had any real issues with the size of system. But removing facebook/gmail/youtube is probably a good idea anyway, since they are all available on the market anyway.

I won't have time to do much work on this for the next few days. Real life. Anyway, hope your hacking yields dividends! :D

Phone blackscreens still on 008. And by the way, the memory performance tweak you added might be the issue with the dalvik being corrupted during shutdown. Can you compile a current version of the kernel with that built in it? Because even with the system partition being freed up, dalvik corrupts itself still, I'm sad to say.
 
Phone blackscreens still on 008. And by the way, the memory performance tweak you added might be the issue with the dalvik being corrupted during shutdown. Can you compile a current version of the kernel with that built in it? Because even with the system partition being freed up, dalvik corrupts itself still, I'm sad to say.

I doubt that the memory tweak is the issue, as that corruption issue occurred for me back when I was using your alpha1.2. Without recompiling the kernel, the easiest way to test your hypothesis would be to run at a lower speed. I think it's an issue that comes from the stock rom itself.

I mean, the OC patch changes the operating frequency of one of the clocks that sets timers for the CPU. By changing that, it changes the operating speed of anything that runs off the same clock. Memory runs off the same clock, but with a divider applied. Normally that divider is set to 3 at 600 MHz (hence 200 MHz AHB clock speed). This means the memory can do one operation for each three cpu cycles. In my OC patch, I changed this to use a divider of 2 (302 MHz AHB clock speed at 604 MHz) by default. This means the memory can do one operation each time the CPU does two.

But this is not (afaict) the internal flash memory, this is the system ram. It shouldn't be affecting things like the cache, unless it works in a totally counter-intuitive way. If it works like I suspect, the cache is built the first time the rom is booted. A copy gets loaded into ram, and a copy is stored on the disk. The version stored on the disk isn't used when the phone is running, the version in ram is. Upon reboot, however, if the flash contains an existing cache, it is loaded from there instead of being rebuilt - this means faster booting.

Now, if the phone is locking and forcibly rebooted, it's possible that the freeze happens during writing the cache to flash memory - reboot halfway through this process and you corrupt some files. Then, upon boot, it tries to load a corrupted cache and gets all screwy.

Also, I'm wary of putting to many versions of the rom out there with subtle variations of each other. I can try removing the memory tweak, but since this issue occurred for me in pre-OC kernels, I strongly suspect it's not the cause.

We could tell the rom to rebuild the cache on EVERY boot, but it would mean slow boot times for every reboot.

*shrug*
 
I doubt that the memory tweak is the issue, as that corruption issue occurred for me back when I was using your alpha1.2. Without recompiling the kernel, the easiest way to test your hypothesis would be to run at a lower speed. I think it's an issue that comes from the stock rom itself.

I mean, the OC patch changes the operating frequency of one of the clocks that sets timers for the CPU. By changing that, it changes the operating speed of anything that runs off the same clock. Memory runs off the same clock, but with a divider applied. Normally that divider is set to 3 at 600 MHz (hence 200 MHz AHB clock speed). This means the memory can do one operation for each three cpu cycles. In my OC patch, I changed this to use a divider of 2 (302 MHz AHB clock speed at 604 MHz) by default. This means the memory can do one operation each time the CPU does two.

But this is not (afaict) the internal flash memory, this is the system ram. It shouldn't be affecting things like the cache, unless it works in a totally counter-intuitive way. If it works like I suspect, the cache is built the first time the rom is booted. A copy gets loaded into ram, and a copy is stored on the disk. The version stored on the disk isn't used when the phone is running, the version in ram is. Upon reboot, however, if the flash contains an existing cache, it is loaded from there instead of being rebuilt - this means faster booting.

Now, if the phone is locking and forcibly rebooted, it's possible that the freeze happens during writing the cache to flash memory - reboot halfway through this process and you corrupt some files. Then, upon boot, it tries to load a corrupted cache and gets all screwy.

Also, I'm wary of putting to many versions of the rom out there with subtle variations of each other. I can try removing the memory tweak, but since this issue occurred for me in pre-OC kernels, I strongly suspect it's not the cause.

We could tell the rom to rebuild the cache on EVERY boot, but it would mean slow boot times for every reboot.

*shrug*

That's a good point. But you know, now that you mention it, back on the HD2 we actually had the same issue and the trick was to rebuild dalvik on boot everytime. Slow boot time is a small price to pay, considering you don't reboot your phone that often usually (I think). And boot time is never over 2-3 minutes... And better that for now than having a slew of FC's to deal with, no?

What would have changed between stock and the alpha that might have caused this I wonder? We can exclude kernel, as this isn't the issue here considering you recompiled it from scratch. Must be something from dsixda's kitchen then. Maybe if we try and redo the ROM from scratch with your kernel in it, clean install the ROM and try again...

I'll keep you posted once my final exams are done!

Thanks!
 
Me again, I think I found the "root cause" of the dalvik crashing:

"Add task killer tweak for speed (stock ROM only)"

I think that's one of the last things I added to v1.2.

Also, found a compatible surfaceflinger, but does not suit my needs.

Also, if you comment out debug.sf.hw=1 in build.prop, phone responds faster. (Placebo? No idea.)
 
Me again, I think I found the "root cause" of the dalvik crashing:

"Add task killer tweak for speed (stock ROM only)"

I think that's one of the last things I added to v1.2.

Also, found a compatible surfaceflinger, but does not suit my needs.

Also, if you comment out debug.sf.hw=1 in build.prop, phone responds faster. (Placebo? No idea.)

I've actually spent a few hours today trying to get a working near-stock rom on the phone to use as the basis for additional work.

I started with the contents of V20A_00.kdz, unpacked it, and tracked down the system.mbn file. After extracting and converting it to a system.img, I loaded it and my updated boot.img into the kitchen and built a rom with the only change being to add root. It hangs at the boot screen when I try to run it on the phone. I can log into the phone with adb shell, though, so it's booting far enough to get a kernel and a bunch of system apps running.

There must be something that LG doesn't include in system.mbn that needs to be in the system.img. Can't figure out what though. Will keep investigating.

Trying a generic cyanogenmod build for the phone right now using only my working kernel as basis. If the recovery programs can be created using that basis, then I hope that I can get a working basic build too.
 
Hey,

I'm looking for close cousins of our phone that currently runs Gingerbread, if you're interested: MSM7000 - Wikipedia, the free encyclopedia

Looking to find a libsurfaceflinger.so that's compatible with our phone. If you find one, please tell me.

Thanks!

Yeah, the kernel patches I applied for overclocking came from the ZTE blade. I've also been looking at the p500 with regard to porting cyanogenmod, since it's quite similar. My gf's phone has this CPU too, but it's s-on locked, which means I can't even permanently root the sucker, nevermind flash another rom.

It actually makes me think our situation is not too bad with this phone - yeah, it's got a few bugs, but generally speaking, it works and is hackable. And with enough similar phones out there, we can even hack with limited skills :D
 
Yeah, the kernel patches I applied for overclocking came from the ZTE blade. I've also been looking at the p500 with regard to porting cyanogenmod, since it's quite similar. My gf's phone has this CPU too, but it's s-on locked, which means I can't even permanently root the sucker, nevermind flash another rom.

It actually makes me think our situation is not too bad with this phone - yeah, it's got a few bugs, but generally speaking, it works and is hackable. And with enough similar phones out there, we can even hack with limited skills :D

It's not THAT bad indeed. But the stock ROM does annoy with the stupid bugs... The custom ROMs make the phone ALOT more livable though! It's actually smooth now... Just wish we could crush that black screen bug and the Dalvik corruption bug. Once those are solved, the overclocked phone with app2sd is everything I'd hoped for!

By the way, head's up:

http://androidforums.com/shine-all-...-off-animation-lg-shine-plus.html#post3635070

Enabled that CRT off animation. ;) Can you test it out for me? Files that are replaced are: libsurfaceflinger.so, libsurfaceflinger_client.so (Both in lib), framework-res.apk and services.jar (framework) and build.prop.

Thanks!
 
I've actually spent a few hours today trying to get a working near-stock rom on the phone to use as the basis for additional work.

I started with the contents of V20A_00.kdz, unpacked it, and tracked down the system.mbn file. After extracting and converting it to a system.img, I loaded it and my updated boot.img into the kitchen and built a rom with the only change being to add root. It hangs at the boot screen when I try to run it on the phone. I can log into the phone with adb shell, though, so it's booting far enough to get a kernel and a bunch of system apps running.

There must be something that LG doesn't include in system.mbn that needs to be in the system.img. Can't figure out what though. Will keep investigating.

Trying a generic cyanogenmod build for the phone right now using only my working kernel as basis. If the recovery programs can be created using that basis, then I hope that I can get a working basic build too.

If you look here: http://androidforums.com/shine-all-things-root/454782-flash-stock-rom-dz-file.html#post3559958

This is my nandroid backup I made immediately after flashing V20A and getting SU/AmonRa installed. Hopefully this can help you.

Also, if it helps I do own an LG Optimus One (P500) as well.
 
Hey, just so you know, I simply turned off the phone and when I booted it, I had FC's all over the place. Still on 007 ROM... Trying to recover from it right now. Something goes wrong with the shutdown of the phone, if it doesn't do a proper shutdown, something gets corrupted. Hard to say what though.
I have been experiencing the exact same symptoms with V008. Sometimes the only way I can get the phone to work again is to boot into RECOVERY and flash V008 again.
 
Hey, just so you know, I simply turned off the phone and when I booted it, I had FC's all over the place. Still on 007 ROM... Trying to recover from it right now. Something goes wrong with the shutdown of the phone, if it doesn't do a proper shutdown, something gets corrupted. Hard to say what though.


hi karendar
can you give me the definition of FC please

thank
 
I have been experiencing the exact same symptoms with V008. Sometimes the only way I can get the phone to work again is to boot into RECOVERY and flash V008 again.

Hi,

Save yourself some grief, don't flash a new ROM... Just boot in recovery, go in Wipe, select Wipe dalvik cache, click ok and reboot phone. It'll rebuild dalvik and everything'll work.

I'm starting to think it has to do with deodexing certain files.
 
LOL, well I'm having fun modding framework-res.apk and the like trying to modify the power menu. Looks like I broke something.

Using APK_Manager, it seems that even decompiling and recompiling framework-res.apk blows it up. I change nothing and it still has issues.
 
LOL, well I'm having fun modding framework-res.apk and the like trying to modify the power menu. Looks like I broke something.

Using APK_Manager, it seems that even decompiling and recompiling framework-res.apk blows it up. I change nothing and it still has issues.

I've decompiled Framework-res.apk many times... But keep in mind if you mod things, systemUI.apk is also a source to look for in Gingerbread, as they seperated it between those two files.

Keep in mind that if you modify framework-res and you don't wanna break my CRT off mod, you'll have to edit res/values/bools.xml, modify this line:

<bool name="config_animateScreenLights">true</bool>

To:

<bool name="config_animateScreenLights">false</bool>

And when you recompile framework-res.apk, say yes to system file, say yes to wanting to edit the files, delete resources.arsc from the keep folder if you modified XML files and if you modified PNG's, delete the PNG's you changed from the keep folder. Then recompile and DON'T sign...

And here's a tutorial on the Extended power menu for the P500, might be very similar to what we have...

http://forum.xda-developers.com/showpost.php?p=11193071&postcount=2
 
I think I'm using the wrong APK_Manager as I'm not getting any of those prompts. I just get the standard menu of choices.

My process went:
adb pull /system/framework/framework-res.apk
put file in modding file for APK_Manager
./Script.sh
Decompile .apk for editing
Immediately recompile .apk for editing (but not signed)
adb push thenewapkthatwasjustcompiled.apk /system/framework/framework-res.apk

But this pretty much blows up the system.
 
I think I'm using the wrong APK_Manager as I'm not getting any of those prompts. I just get the standard menu of choices.

My process went:
adb pull /system/framework/framework-res.apk
put file in modding file for APK_Manager
./Script.sh
Decompile .apk for editing
Immediately recompile .apk for editing (but not signed)
adb push thenewapkthatwasjustcompiled.apk /system/framework/framework-res.apk

But this pretty much blows up the system.

That pretty much sums up the process except for the part I added during recompile. Do you have APK manager 4.9?

adb pull /system/framework/framework-res.apk
put file in modding file for APK_Manager
script
Option 22 (Select project framework-res)
Option 9 (Decompile)
Option 11 (compile, Yes to system app, Yes to modify files before compiling, delete resources.asrc in keep folder, return in APK manager, hit enter)
adb push thenewapkthatwasjustcompiled.apk /system/framework/framework-res.apk

done. Loop. Rince. Repeat.
 
Back
Top Bottom