[Q] Bootloop logcat e/sdcard missing packages.list - Android Q&A, Help & Troubleshooting

I am trying to boot an AOSP-based ROM that I compiled the other day but it won't get past the "google" screen, it wouldn't even get to the splash screen of the ROM. I pulled a logcat and it shows "E/sdcard missing packages.list". I have googled, xda search, etc. but nothing really came up. Someone mentioned trying to enable VT-x but I already have that enabled so I don't really see that being the issue. I have included the pastebin of the logcat; when I copy/paste into pastebin it pasted all weird so sorry for that but the error is at the end.
http://pastebin.com/embed_js.php?i=V0NMawes
Any help would be greatly appreciated.

sdcard is not a serious problem (will be big problem later though). Your framework env may be incorrect, and you maybe got a wrong ramdisk. (ART is failing create boot.oat.) Also, your audioflinger is dead.(Big issue) It may be caused incompatible vendor lib, etc. Your paste is too hard to read. Get less line changes.

Related

Rom first run errors - logcat

Well I built a custom rom for myself the other day, using the latest stock htc rom (HTC Generic 2.73.405.66), and the kitchen floating around on these forums. It flashes fine, after a full wipe.
Then it freezes on the Hero boot screen.
I used adb logcat to find the issue. I cant post the exact output now, but here is the basic problem:
loading libandroid_servers.so 0x0
its unable to load since it cant find the file: libandroid_servers
System crashes, and restarts. It does it over and over again.
Now im not sure how to solve it, but ive checked that the file libandroid_servers.so is included in the right folder, and and is spelt correctly (including case-sensitive wise)
Anyone else have/had this problem? and a solution?
Also i will say that im not exactly a nub at this. Ive had years of flashing and modification experience on different os's and platforms.
Thanks for any assistance that anyone can give
a few lines more from the logcat might help. the last line is not always the problem indicator. best is probably to attach a complete logcat from the boot, please attach a textfile or use a pastebin service, do not paste the log in your post.

phone force closing

I have been talking this over with Condemned Soul but wanted to see if anyone else has ran into this problem since he & I are both confused.
My fiances phone has been force closing a lot lately aka com.android phone not responding. I saw the first force close when I tried flashing Tazzs cm7 on his phone so thats when I first put on gsb 1.2
I switched his over to Sheds GSB on the 8th and it was great everything was fine but then I decided to try to improve on a few settings and when I restarted the phone it decided to start force closing.
I reflashed the rom and the gapps and everything seemed fine but then I wanted to put cs skull theme on his phpne since we had it on Kaos v9 but then when I restarted the phone after flashing the theme it force closed again.
So then I reflashed the rom and gapps again and got all his apps and settings all back how he had it and decided to do a Nandbackup so that we wouldnt have to keep reflashing the rom again and once I restarted the phone after the nandbackup it force closed again.
Long story short I reflashed the rom and gapps and now am in the process of getting his apps and settings back how he had it once again.
Am I doing something wrong to make it keep force closing? I would like to make a nandbackup at least for him so that we wont have to keep setting up his phone.
Thank you for any help
When you say you flash the ROMs, do you also do a wipe beforehand? If not, try doing a wipe and then install and see if that changes anything.
Yes I wiped both the factory and dalvk sorry I thought I mentioned that. lol.
labnjab said:
Yes I wiped both the factory and dalvk sorry I thought I mentioned that. lol.
Click to expand...
Click to collapse
Its a problem that happens on certain ROMs with certain themes. Not sure there's a fix for it, I just got around it by not applying the phone.apk theme.
zerocool79346 said:
Its a problem that happens on certain ROMs with certain themes. Not sure there's a fix for it, I just got around it by not applying the phone.apk theme.
Click to expand...
Click to collapse
phone.apk wasn't changed in the theme. Strange part is it's only on the one phone and haven't heard of it on any of the others.
CondemnedSoul said:
phone.apk wasn't changed in the theme. Strange part is it's only on the one phone and haven't heard of it on any of the others.
Click to expand...
Click to collapse
That is odd.
Update:
This is still causing issues. Going to try and format the sd like tazz suggested, but moving my phone.apk to his didnt work, and yesterday he had to restart his phone and it did it again and needlessto say hes not very happy with his phone. Says its not reliable at all. If anyone else has anything else I can try it would be a big help. I have tried searching on google but dont find a whole lot of information. I just wish I could figure this out its got to be something I did or something stupid that I am missing.
There are a couple of next steps you can take.
If the problem is a software configuration issue, then it is possible that you will see the reason for the FC in the logcat.
The system logcat is designed as a "circular buffer" (in a way that it has a maximum size) - once you fill it to capacity, each new record which is added to the end causes information at the beginning to be lost. But, this also means that if a FC occurs, so long as you "dump the logcat" within a reasonable period of time after the FC happens, you will capture the moment in time that the FC occurred,
Generally, the "logcat" buffers get filled to capacity quite quickly at boot time (because there is lots and lots of "android" app activity), and quite a bit slower after the phone has been completely booted. If you are trying to capture a logcat event during the first boot, you need to continuously capture output to a file on your PC (it will be quite large) - but once the phone has completed booting, so long as you "run a logcat" within 5 or 10 minutes after a FC occurs, the relevant event(s) will be in the logcat.
If you want to capture it during the first boot cycle of a freshly flashed ROM, probably you ought to have a PC attached and dump the prodigious output to a file on the PC, as in
Code:
C:\MyWindozePC> adb shell logcat -v time > LogcatFileOnMyPC.txt
So long as the ROM you have flashed has "USB debugging" turned on by default, you can run the above command about 10-15 seconds after you see the 3 skating droids, and it will continuously place output into the local file on your PC. You need to interrupt the above command (Control-C) to get it to stop; you would usually do that a few seconds after you saw the FC, and then you would know that the log entries you are looking for at the end of the file.
(Note that logcat dumps are usually huge - don't bother trying to look at them with a text file viewer on the phone - they suck at handling large files... well, at least the ones that I have tried).
You could also instrument this on the BF's phone in a way where he can capture the info to the SD card anytime he is using the phone during the day with a couple taps of the screen, and then you could look at the logcat(s) later at your leisure - for instance by using Gscript Lite, and a simple script like this:
Code:
#! /system/bin/sh
_LOGDIR='/sdcard/logcats'
if [ ! -d ${_LOGDIR} ]; then
mkdir ${_LOGDIR}
fi
_tstamp=`date +%Y%m%d-%H%M`
logcat -v time -d > ${_LOGDIR}/logcat_${_tstamp}.txt
With this method, you just need to train him like a monkey to press the right keys after a FC occurs. If he's a clever monkey, you could even train him to send the logcat files to you via e-mail.
If the problem is due to an intermittent hardware issue with the phone, that will be tougher to identify. About the best you can do to make that determination is to return the phone software to stock and use the phone without installing any apps for a reasonable period of time and see if the problem continues to occur.
cheers
bftb0
Thank you for the detailed reply bfbt0 I was about to msg you when you responded.
I will have to give what you mentioned a try.
Is the gscript lite what I use for the adb shells or do I need another app as well. I have never done anything with adb or if I have it was something simple.
To clarify I would have to get his phone to fc again which is easy to do and then run a logcat. It sounds easy through the pc I just want to make sure I do it right. I would make a folder dedicated to where the logcats would be stored and then run it in the gscript lite? Meaning run the first code you posted.
Update ~ Never mind I found you had to have android sdk on your pc Im downloading that now. I still may need help tho.
labnjab said:
Update ~ Never mind I found you had to have android sdk on your pc Im downloading that now. I still may need help tho.
Click to expand...
Click to collapse
GScript Lite is a free app on the market. It was put together by XDA member "rogro", and he has a paid version as well if you want to throw a couple bucks his way.
Using the script above with Gscript (Lite or Pro), you don't need to be tethered to a computer nor set up the SDK and drivers. (Only when you want to capture a full first ROM boot do you need to use a PC (because the logfile grows so big in that specific case).
If you can force the FC to occur, then using the Gscript Lite script I showed above will capture the information you want.
bftb0
PS There is a brief outline of how you load a script into Gscript Lite in that "Universal Root for Dummies" thread over on AF.
cheers
Thank you I will try that tonight and hopefully can figure out what the issue is
labnjab said:
To clarify I would have to get his phone to fc again which is easy to do and then run a logcat. It sounds easy through the pc I just want to make sure I do it right. I would make a folder dedicated to where the logcats would be stored and then run it in the gscript lite? Meaning run the first code you posted.
Click to expand...
Click to collapse
That code I posted checks to see if a folder exists, and if not creates it - /sdcard/logcats
No need for you to do it manually; the first time the script runs it creates that folder
But, yeah - wait for the FC to happen and then run that script within the next couple of minutes (no real hurry). It is also useful to make note of the time the phone displays when the FC occurs - it will be easier to find things in the logcat file by timestamp if you do that.
bftb0
Thank you I will do that as well. Thanks also for taking the time to help me.
I did the code on my phone to make sure I did it right and it gave me an error
says cannot create/logcat_20110222-1558.txt read only file system
did I do something wrong, just want to make sure that I can get it right before attempting it on his phone tonight. Thanks in advance.
labnjab said:
I did the code on my phone to make sure I did it right and it gave me an error
says cannot create/logcat_20110222-1558.txt read only file system
did I do something wrong, just want to make sure that I can get it right before attempting it on his phone tonight. Thanks in advance.
Click to expand...
Click to collapse
If you typed that script in by hand, you made a typo.
I checked it by cutting and pasting it - and then I tested it afterward, and it worked.
Probably you bolluxed up the _LOGDIR variable, or you inserted a space in the logcat command where there should not be one.
I would suggest that you cut and paste, rather than type.
Hmmmm... it occurs to me that those little "scrolling CODE text boxes" don't render correctly on the phones browser. Here's the same script, but without enclosing it in [ CODE ] [ /CODE ] tags:
#! /system/bin/sh
_LOGDIR='/sdcard/logcats'
if [ ! -d ${_LOGDIR} ]; then
mkdir ${_LOGDIR}
fi
_tstamp=`date +%Y%m%d-%H%M`
logcat -v time -d > ${_LOGDIR}/logcat_${_tstamp}.txt
Thank you for all your help. I got it to work and come to find out I didnt even need to use that program because it hasnt forced closed yet. He said he wiped the phone a bunch of times the other day when he was trying to get it back up and running when it forced closed on him while at work and now i rebooted it and backed it up and that usually caused a problem, so far so good.
I am tho going to format the sd card and redo the rom again just to be sure this problem doesnt happen again. Thank you again for all the help.
On some builds (even though it shouldn't be required) it is necessary to wipe multiple times. On Tazz's earlier builds of GB, people reported having to wipe 3x or more to get it running smooth. Always make sure you do a nand backup before flashing in the future lol. Hopefully the phone stays running good! If not, people are always here to help!
Sent from my Ginger Tazz using XDA App

[DINC] Porting = discouragement

Why oh why can I not get anything to boot on my gosh darn incredible? I've tried everything except making it all work.
I want so badly to get something to boot, but alas it never happens. Stuck at the white screen is as far as I ever get. I don't even get the satisfaction of seeing a bootloop, at least then I'd be seeing some sort of progress. Its disheartening. I've tried all kinds of roms and system dumps to no avail.
There must be something I'm doing wrong, what?
Sent from my ADR6300 using XDA Premium App
Do wipe data and cache before flashing?
Yeah. I did manage to get a boot loop with the huashan gingersense leak. So some progress.
Sent from my ADR6300 using XDA Premium App
Give more detail, and I might be able to help. What steps are you taking to port the ROM?
You need a kernel from your device at least. You also need to change some entries in build.prop and rename the init.devicename.rc to your device's name and not the original ROM's. Then you need to replace any device specific drivers and libs with ones from your device. And then, it still might not work. There's a lot going on here.
I'm assuming that by 'porting' you mean taking an existing ROM from another device and making it work on yours. The word has a different meaning also, which is take AOSP/CM/whatever and make it work on a device that it doesn't currently work on.
gnarlyc said:
Give more detail, and I might be able to help. What steps are you taking to port the ROM?
You need a kernel from your device at least. You also need to change some entries in build.prop and rename the init.devicename.rc to your device's name and not the original ROM's. Then you need to replace any device specific drivers and libs with ones from your device. And then, it still might not work. There's a lot going on here.
I'm assuming that by 'porting' you mean taking an existing ROM from another device and making it work on yours. The word has a different meaning also, which is take AOSP/CM/whatever and make it work on a device that it doesn't currently work on.
Click to expand...
Click to collapse
Thanks I've swapped the boot.img, changed the build.prop, didn't rename the init file I instead copied over it. Copied the wifi modules, all the missing libs, the usr folder, bin folder, etc folder, and xbin.
Problem is when I change the libs it never gets past the splash, but when I change just the boot.img it'll boot loop.
And yes I mean from one device to another.
Sent from my ADR6300 using XDA Premium App
Mr. Rager said:
Thanks I've swapped the boot.img, changed the build.prop, didn't rename the init file I instead copied over it. Copied the wifi modules, all the missing libs, the usr folder, bin folder, etc folder, and xbin.
Problem is when I change the libs it never gets past the splash, but when I change just the boot.img it'll boot loop.
And yes I mean from one device to another.
Sent from my ADR6300 using XDA Premium App
Click to expand...
Click to collapse
Personally, I wouldn't copy entire folders over. I also wouldn't copy the boot.img over. I'm not saying that it won't work in some cases. It might. I've always swapped the kernels inside the boot.img, and renamed the device specific init file. Then, I would compare the init files from an existing ROM for my device with the init files from the ROM that I'm trying to port and see if there are any lines that are device-specific. If the init file is trying to start up something that doesn't exist on my device, then it doesn't make sense to keep that line. On the other hand, there might be a line that changes something for that ROM that IS needed.
This same thing kind of goes with the libs and other files too. You might have one lib that relies on another lib being there. And it might need a particular build of that lib. And other files might call certain libs. This is one reason that building from source generally works better over the long run than trying to get one device's ROM to work on another.
You have device specific and ROM specific things going on at the same time, so wholesale copies tend to miss one or the other. Plus it's nice to dig in and get an idea about what's going on.
Also, if you can get adb access while it's booting, grab a logcat. It might give you an idea about what is failing.
I re-did the boot.img by replacing the kernel and renaming (in this case) init.hua_shan.rc to init.inc.rc. It gets past the "HTC Incredible" splash. So, that's a plus.
I did get a logcat, as I always do when I flash a new rom that hasn't been tried before. I use pastebin so take a 'gander' at it if you will.
From the looks of it Alsa, bouncycastle, and audio libs are having problems. Oh, and the bootanimation.zip didn't get dumped from the Huashan, but it's no big deal.
http://pastebin.com/VVxufgQL
Oh, and thank you for the help you have provided thus far.
Mr. Rager said:
I re-did the boot.img by replacing the kernel and renaming (in this case) init.hua_shan.rc to init.inc.rc. It gets past the "HTC Incredible" splash. So, that's a plus.
I did get a logcat, as I always do when I flash a new rom that hasn't been tried before. I use pastebin so take a 'gander' at it if you will.
From the looks of it Alsa, bouncycastle, and audio libs are having problems. Oh, and the bootanimation.zip didn't get dumped from the Huashan, but it's no big deal.
http://pastebin.com/VVxufgQL
Oh, and thank you for the help you have provided thus far.
Click to expand...
Click to collapse
Did you also change the ro.board.platform parameter in build.prop so that it matches the chipset name originally on your device?
Also, the next time you flash this ROM, dump the recovery log file before you reboot. This may show you errors encountered during the flash which were not shown in the normal output. A common error is porting a large ROM - such as Desire HD's - to a device with a small system partition in comparison. A workaround is to remove unneeded apps under system/app to reduce size of the ROM.
You may also want to try the Porting option in my Android Kitchen, it does the renaming, kernel and driver modifications for you.
dsixda said:
Did you also change the ro.board.platform parameter in build.prop so that it matches the chipset name originally on your device?
Also, the next time you flash this ROM, dump the recovery log file before you reboot. This may show you errors encountered during the flash which were not shown in the normal output. A common error is porting a large ROM - such as Desire HD's - to a device with a small system partition in comparison. A workaround is to remove unneeded apps under system/app to reduce size of the ROM.
You may also want to try the Porting option in my Android Kitchen, it does the renaming, kernel and driver modifications for you.
Click to expand...
Click to collapse
I've had a busy past couple of days, but I'll check into the recovery dump and see what's up. I did change the ro.board.
I was trying to abstain from your porting tools, no offense, only so I could do it manually. Just trying to gain more experience, I guess, and learn. Your kitchen is excellent. I use to set up my environment and deodex among other things. The porting tool, though greatly eases the pain and shorten the manual labor ( yes lazy America) , take the learning curve out, a bit. But I guess I could take a look at the script to see what's going on too. Lol.
EDIT#1 - So I just tried to flash my rom. However, it wouldn't, because for some reason my phone is very particular about how one copies files over to the sd card. For one, you have to have the phone booted up, MIUI GB latest in my case, and mount usb storage. If I mount it through recovery, it corrupts my sd card, too bad I wish I knew that earlier. It's a PITA really...Ubuntu...
But, as phone WAS:
Hboot - 0.92
Radio - 11.19
Ship S - OFF
I tried copying and flashing through recovery. Fail as usual. So, I was gonna boot up into MIUI and try to copy from there, and got the infamous 5-vibe and twinkle.
I tried several times to boot into MIUI, but after many battery pulls, I figured out something ODD. In the bootloader the first couple of times it skipped the scanning process, then it started scanning again. Upon further inspection:
Hboot - still 0.92
Radio - still 11.19
Ship S - ON <---NOT A TYPO
Why? I haven't a clue. I tether my phone, so I got it booted, yay, but to do it, my sd card has to be removed and my usb plugged in, then turn on. So, my next edit will be a progress update. AFTER I s-off again ( that sounds kinda dirty, lol ), and re-format my sd. Also, my phone thinks it's charging...ITS UNPLUGGED. Lol, infinite-charging batteries, it's the future...
Sent from my ADR6300 using XDA Premium App
So...Good news is I got another incredible with amoled screen
Bad news I got another incredible with nothing on it, or rooted :-( But I rooted it before I even activated it with *228
But, alas, I still have all of my work on my computer. I managed to back it up before my phone crapped out. Plus I kinda get to start from the beginning so I can be more observant, and particular.
So, back to work...will update tonight.
Edit 1 - So after some more tinkering I've managed to fix some issues, but others have popped up namely the HTC Sim card authentication, which I have no idea about, yet, bouncycastle.jar is being stubborn by not fiding its classes, and libaudioflinger.so is failing to link to libsystem_server.so which in turn fails the link to libandroid_servers.so. Same three problems as before it seems.
Here's a pastebin of the logcat.
http://pastebin.com/QYde7fuQ
I'll keep tinkering about and see what I can come up with. Hopefully I'm closer to getting this thing booted up than I think.

[Q] AssetRedirectionManager: Unable to attach target package assets for APK

So I'm trying to use the MIUI radio (which functions on the latest Defy-based build for the DX) on CM7. I figure it should work given a little trickery. I resigned the APK, pushed it to /system/app, set the permissions, and rebooted, but it didn't work. I checked the logcat and this is the relevant line:
W/AssetRedirectionManager( 1718): Unable to attach target package assets for com.miui.fmradio
I don't know what that means. I was hoping someone could help me out? I've seen similar logcats on these forums, but never directly addressed by the thread topic. Attached is the full logcat from boot.
Any insight, either on my specific problem or general APK/assets/resource knowledge would be greatly appreciated.

Blank Jobs.xml Generated Repeatedly; Causes Bootloop

I'm on an LG G3 D850 with LG-MM-Stock-Based CleanRom 2.8 installed, but I don't think that is super-relevant to the issue at hand aside from the MM part... so this is going in the general Android Q&A forum
I recently had to reinstall my ROM from scratch, re-setup my whole system, etc. Since that time, I've been finding that whenever my battery fully depletes, I end up in a bootloop when I next turn on the phone.
This bootloop looks like getting the "Optimizing Apps" window, going through all 200-something of my apps, and when it completes... rebooting and starting over again
I eventually managed to go into TWRP, and modify some system settings to enable adb from my computer in the system, so I could use logcat to see what was going on during boot. I discovered a fatal error whenever it would finish the app optimization, that looked like:
Code:
AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: main AndroidRuntime: java.lang.RuntimeException: Failed to create service com.android.server.job.JobSchedulerService: service constructor threw an exception
Googling this, I found the following StackExchange: Marshmallow not bootlooping, but not starting
Basically, it turns out that empty / corrupted .xml files for key system activities can cause this to happen on startup
In my case, it was the jobs.xml file in /data/system/job –*and deleting it would allow the phone to reboot, no problems.
---
So I know the fix to this issue.
The problem is, whenever my battery drains all the way... there's like a 50% chance this happens again. It's happened a good 4-5 times over the past week
I'm trying to figure out wtf is causing this.
Can anyone give me some insight, maybe a path to follow to figure out what's creating these empty jobs.xml files, a better understanding of what the job scheduler / jobs.xml files are for, a way to automate deleting the jobs.xml file every so-often if it's empty, a boot-script that can flush it when I restart my phone... anything like that?
I'm really sick of having to go through this, esp. since when it happens, I usually also have just had to wait for my phone to get enough juice to startup... so it's massively inconvenient to also have to go into recovery and delete the file :/
(FWIW I've tried every common fix I can think of... reflashing the ROM, clearing caches, etc. etc.)
phnord said:
(FWIW I've tried every common fix I can think of... reflashing the ROM, clearing caches, etc. etc.)
Click to expand...
Click to collapse
Maybe you can create a init.d script to delete the file when startup if your device support it.
Hit the thanks button if I helped you
Could I get a walkthrough on this? How do I create an init.d script / what should syntax look like / where do I store it to have it execute the moment of boot / do I need to do anything to grant it special permissions of some kind / etc.?
Would something as simple as creating a 00 file that I store in /system/init.d that contains:
Code:
#!/system/bin/sh
rm /data/system/job/jobs.xml
chmodded to 777
Do the trick?

Categories

Resources