[Q] Camera quit working, says Gallery has stopped - logcat - Samsung Galaxy Nexus

I have the GSM i9250 and love the phone. Got the 4.3 OTA update on Wednesday afternoon. It was updating while driving to a golf match and all seemed well.
During the golf match, a small amount of beer was dripped on my phone (it was in the cubby hole and my team mate tossed a crumpled empty beer can in there). I didn't think anything of it, but when done, there was enough beer to line the inside of my diztronic case and render the power button nonfunctional.
I took it apart, cleaned it all up, cleaned up the power button and all is well again. The next day I went to fire up my camera and got "Unfortunately, Gallery has stopped." I popped everything apart, cleaned it all again, checked connections, etc, same problem. I flashed the official 4.2.2 image (bootloader, radio, system, data, user), same problem. It got the 4.3 OTA again, so I upgraded. I also borrowed the camera out of a co-worker's phone and same problem.
It seems like a software issue, but if something is toast due to the beer spillage, it may not even be able to fire up the camera.
I flashed CWM and ran fix permissions, same problem.
This is the most pertinent info here:
Code:
E/CameraHAL( 127): Couldn't get camera properties
W/dalvikvm( 4634): threadid=18: thread exiting with uncaught exception (group=0x418e4700)
E/AndroidRuntime( 4634): FATAL EXCEPTION: Thread-404
E/AndroidRuntime( 4634): java.lang.RuntimeException: Fail to get camera info
E/AndroidRuntime( 4634): at android.hardware.Camera._getCameraInfo(Native Method)
E/AndroidRuntime( 4634): at android.hardware.Camera.getCameraInfo(Camera.java:202)
E/AndroidRuntime( 4634): at com.android.camera.CameraHolder.<init>(CameraHolder.java:169)
E/AndroidRuntime( 4634): at com.android.camera.CameraHolder.instance(CameraHolder.java:123)
E/AndroidRuntime( 4634): at com.android.camera.Util.openCamera(Util.java:316)
E/AndroidRuntime( 4634): at com.android.camera.PhotoModule$CameraStartUpThread.run(PhotoModule.java:294)
W/ActivityManager( 375): Force finishing activity com.google.android.gallery3d/com.android.camera.Camera
Since it says CameraHAL, I'm assuming that's an actual hardware failure.
Anyone have some insight?

I'm with my Galaxy Nexus in the same situation, after install JB update (4.2.1), the camera stopped work as well playing videos on youtube too, I already have made the installation of 4.3 version but I still get the same error, I'm planning to clean my motheboard and check if it's evertything correct.
Anyway, please, let me know about your results too.
Regards.

I'm still having issues with it, but now I can't even open Gallery.

I got it fixed, so far anyway.
Used fastboot to erase boot, system, userdata, cache, and recovery. Then ran fastboot format on all as well (won't format boot). When that was done, I fastboot flashed the 4.2.2 bootloader, rebooted into bootloader, then flashed boot, recovery, system, and userdata for 4.2.2.
After reboot, my camera works again.
**EDIT**
Got the 4.3 OTA and camera still works.

cougar694u said:
I got it fixed, so far anyway.
Used fastboot to erase boot, system, userdata, cache, and recovery. Then ran fastboot format on all as well (won't format boot). When that was done, I fastboot flashed the 4.2.2 bootloader, rebooted into bootloader, then flashed boot, recovery, system, and userdata for 4.2.2.
After reboot, my camera works again.
**EDIT**
Got the 4.3 OTA and camera still works.
Click to expand...
Click to collapse
Oh, I'm gonna give it a try, well, it might be the same issue that I'm having. My phone stop camera working with the 4.2.1 update, I have flashed 4.3 and still the same error. But the back camera works on apps like Facebook or Lomo Cam, when I select front camera it gives me a error such as a crash or even a information saying that the app wasn't able to connect to the front camera. I'll first clean the front camera contact and later I'll try your solution.

Clear the logcat, run logcat and force the error message. It may be a faulty front camera.

I have tried it, but, it didn't work. :/

From your description, I didn't think it would. Does the proximity sensor work?

Yeah, all these stuff work except for the camera, actually, only the front camera. I have installed some other camera apps such as Lomo Cam and Night Vision, I those apps I can take a photo or even record with the rear camera but when I select front camera or even camera configurations, its crashes. I already have opened my phone and cleaned the things there but no sucess. Is there a way to use stock camera app? Because I want photosphere but it seems like that everytime it opens, it tries to get camera info from both cameras and when it doesn't get the front one, it crashes.
PS: my log is just like yours, crashing in getting camera info

Related

[Q] Random reboots and frustrating boot loops

Hey all,
I've been having boot-loop problems for almost a month now. The phone just abruptly reboots and goes into a boot loop with just the HTC screen. The problem is fixed temporarily if I remove the battery for a while and then power it back up. If I start having too many things going on, such as several tabs in DolphinHD, downloading several updates, etc. [no gaming at all] it'll do the same thing and just reboot.
I was running Cyanogen 6 [stable] with Kingxkernel #2. I was not overclocked, but did have a few setcpu profiles active. I've tried everything imaginable since they began:
-Tried a different kernel [SNAP], didn't work
-Truned off setcpu, didn't work
Today, I got fed up with everything and then decided to flash a Sense ROM hoping that that would fix everything. I flashed the latest Fresh and after the install, even before I could skip all the set-up stuff, the phone started to reboot again.
As for the Fresh installation, I wiped fully including dalvik and cache all in RA.
I'm about to go crazy. I wan't my fully functioning phone back. Please help
EDIT: Also, I forgot to mention that around the same time the random reboots and bootloops began I got a new battery. It was the one from Best Buy made by Seido. Idk if that would affect anything seeing as I get the same problems with both batteries.
if i was you i would do all the following:
1. titanium backup all your apps...
2. flash clockwork recovery
3. nandroid backup everything
4. wipe /system
5. wipe /data
6. wipe /boot
7. wipe /cache
8. wipe /dalvik
9. install rom of your choice
10. run it for a few hours and push it as hard as you can to cause a reboot
- if it reboots -> plug into computer load up terminal/command prompt do adb logcat (copy and paste where and why it reboots)
- if it doesn't reboot -> start reinstalling your apps one at a time or in batches until you find the culprit (unlikely since most installed apps should only cause a force close rather than a reboot but still worth a shot)
11. post back with your findings... ?
fyi the nightly builds seem more stable than the stable build ever was... at least to me on my evo it was...
Thanks for the reply.
I'm going to try that to see what happens. I'll post asap.
Alright, I flashed Clockwork as you said and wiped/formatted everything you mentioned. After that, I flashed Fresh. Everything went well until it went through it's first routine reboot after flash; I didn't even get to pull down the lockscreen into activation before it randomly rebooted. I did a logcat on the first reboot. This is a little piece of the last part of that:
V/libgps ( 292): DeferredActionThread pthread_cond_wait returned
V/libgps ( 292): PA event: 0x00000040
V/libgps ( 292): PDSM_PA_EVENT_GPS_LOCK 0
D/dalvikvm( 292): GC_FOR_MALLOC freed 618 objects / 115992 bytes in 145ms
I/ActivityThread( 674): Publishing provider com.htc.dcs.provider.utility: com.htc.dcs.service.utility.UtilityProvider
D/dalvikvm( 292): GC_FOR_MALLOC freed 55 objects / 177104 bytes in 74ms
D/dalvikvm( 292): GC_FOR_MALLOC freed 296 objects / 253256 bytes in 86ms
I/ActivityThread( 674): Publishing provider com.htc.sync.provider.weather: com.htc.sync.provider.weather.Provider
D/ConnectivityService( 292): getMobileDataEnabled returning true
I/ActivityThread( 674): Publishing provider com.htc.socialnetwork.snprovider: com.htc.socialnetwork.provider.SocialNetworkProvider
horiveira:tools stgomez91$
Click to expand...
Click to collapse
It rebooted after the second to the last line. This is my first time using logcat, so I don't know too much about what any of that stuff is, except for the last line obviously.
Can anybody tell the reason why I get these problems by looking at that?
Here's a copy of the logcat file: http://www.sendspace.com/file/kt3lj1
I was hoping this would work, but alas...it did not. What do I do now??
Had the same problem.
For me the solution was to reset the GPS and after that all the random reboots stopped.
Dial : ##GPSCLRX#
Enter your MSL Code
let the phone reboot.
I hope this works for you.
How do you get your MSL code?
Gonna try that now, I hope it works...
How did you figure out it was the GPS?
EDIT: Just tried what you suggested. Didn't seem to work: after it rebooted and got past the Fresh screen, it rebooted without me touching it.
jthurs said:
How do you get your MSL code?
Click to expand...
Click to collapse
Use MSL reader, it's in the Market (and free).
Alright, after doing what aj74 mentioned and it not working, I left the battery out for a bit then powered it back on. That was at 3pm. At around 4, it had yet to reboot so I decided to restore all of my apps with Titanium Backup. I have yet to have a random reboot, though I highly doubt it's fixed.
I'm afraid to use my phone :-/
same problem. looks like this is becoming more and more frequent. i have tried unrooted, and a bunch of rooted roms. this is a problem that needs solving fast.
lo' and behold, as I was getting confident and rearranging things on the phone the loops began again.
I guess I feel better
Well, I feel better since it isn't just me. It has been working fine, then I took the phone on my first trip and as soon as I got off the plane on Wednesday, the random restarts started.
I'm guess some type of app update caused it, but god only knows which one. I did a factory reset, the gps reset, restored a nandroid backup from late september, and turned off all synching. Still get the reboot loop.
I seem to be able to make it stop for a little while by putting the phone in the freezer, but I can't believe we would all start having this problem at about the same thing if it was simply a overheating issue.
Update:
I was roaming when all of this happened, and now that I'm home, I haven't been able to get the phone to mess up. This will make it tough to take in for service. It still may be a heating issue, however, since it is not hot where I live, but it was hot where I was visiting.
Update 2:
I have now been able to get the problem to happen in my home area. The battery temp was > 100 F when it happened.

[SOLVED in 2.3.6] Gingerbread 2.3.5 JQ3/JQ4 (soft) reboot issues (random + MicroSD)

UPDATE: [SOLVED] Looks like the GingerBread 2.3.6 ROM fixed this issue.
When the MicroSD card is scanned at startup (i.e. the card is already inserted when the device starts), the MediaScanner / PackageManager analyses the card and this seems to generate a deadlock within the system_server process (.ServerThread), which results in a soft reboot. I don't know if this happens only when there are Apps2SD files (I didn't test this particular edge-case).
So, quite simply, I just insert the MicroSD card once the device is completely booted
UPDATE: sometimes the reboot occurs in this case too, so the deadlock is not completely unavoidable. However, if I long-press the search button, the system doesn't respond which generates a Force Close popup dialog for "Android System" => if I force-close this process, then the device starts responding again and everything works as normal!
Additional note: the MicroSD is perfectly stable when connected in USB transfer mode.
----------
Stock JQ3 has been rebooting randomly on my Tab (no obvious error message in logcat, disabled overclocking/undervolting, Koxudaxi or Overcome kernels, RFS or EXT4 filesystem)...sometimes I can use the Tab for days without problems, but today it keeps rebooting (with or without any interaction from my part).
UPDATE: confirmed with JQ4 too.
The logcat reveals that the watchdog detected a
system-process deadlock, and forced a full restart of the Android
runtime. Here's what [/data/anr/traces.txt] says for .ServerThread (system_server):
Code:
"android.server.ServerThread" prio=5 tid=10 SUSPENDED
| group="main" sCount=1 dsCount=0 obj=0x4050fc58 self=0x2f34a8
| sysTid=12309 nice=-2 sched=0/0 cgrp=default handle=3093984
at java.util.HashMap$HashIterator.hasNext(HashMap.java:~791)
at java.util.AbstractCollection.toArray(AbstractCollection.java:356)
at com.android.server.PackageManagerService.getInstalledPackages(PackageManagerService.java:2385)
at android.app.ContextImpl$ApplicationPackageManager.getInstalledPackages(ContextImpl.java:2186)
at com.android.server.BackupManagerService.allAgentPackages(BackupManagerService.java:966)
at com.android.server.BackupManagerService.addPackageParticipantsLocked(BackupManagerService.java:874)
at com.android.server.BackupManagerService$1.onReceive(BackupManagerService.java:836)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:709)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:130)
at com.android.server.ServerThread.run(SystemServer.java:673)
"android.server.ServerThread" prio=5 tid=10 SUSPENDED
| group="main" sCount=1 dsCount=0 obj=0x4050fc58 self=0x2f34a8
| sysTid=12309 nice=-2 sched=0/0 cgrp=default handle=3093984
at java.lang.String.compareTo(String.java:~60)
at java.util.ComparableTimSort.mergeLo(ComparableTimSort.java:650)
at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:447)
at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:370)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:178)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:142)
at java.util.Arrays.sort(Arrays.java:1974)
at com.android.server.PackageManagerService.getInstalledPackages(PackageManagerService.java:2388)
at android.app.ContextImpl$ApplicationPackageManager.getInstalledPackages(ContextImpl.java:2186)
at com.android.server.BackupManagerService.allAgentPackages(BackupManagerService.java:966)
at com.android.server.BackupManagerService.addPackageParticipantsLocked(BackupManagerService.java:874)
at com.android.server.BackupManagerService$1.onReceive(BackupManagerService.java:836)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:709)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:130)
at com.android.server.ServerThread.run(SystemServer.java:673)
More information here:
http://www.google.co.uk/search?q=reboot+Sending+signal+WATCHDOG+KILLING+SYSTEM+PROCESS
I got reboot whenever I enable wifi.
Hadn't test anything more than this.
Reverse back to dxjpj asian rom
Yes, I realized Wifi would potentially be the cause of the problem, so I am in "flight" mode with both wifi and cellular off.
This is clearly a "system_server" reboot (i.e. the adb connection via USB to my laptop remains alive), so I can capture the system logs even whilst the system is rebooting. Here's some info I found in a mailing list:
Code:
Runtime restarts are almost always for one of two reasons: either a
component running in the system_server process has crashed outright,
or something has caused the system_server's process primary looper
thread to deadlock. The deadlock case is announced by a line in the
logcat buffer reading something very like this:
04-04 14:06:16.888 885 1089 W Watchdog: *** WATCHDOG KILLING SYSTEM
PROCESS: null
I'm going to talk about the NON-deadlock cases first; they're simpler
to diagnose: just look in the logcat trace for the messages about the
system process crashing. There will be a Dalvik stack trace there to
the point at which the fatal exception was thrown, and you then know
where to go looking for the bug. As always, the event log and the
primary text log contain different information; both are useful for
reviewing the state and activity of the device leading up to a crash.
If the crash *was* due to a deadlock, things get a little interesting.
When the watchdog declares a deadlock and forcibly kills the system
process, it first captures the current stack trace of every
system_server process thread into the usual ANR stack trace file
(/data/anr/traces.txt on most devices). This file is automatically
included in a bugreport -- yet another reason to pull a full bugreport
rather than just logcat.
Look at the timestamp of where the watchdog declared a problem. In
the example line I gave above, it was 04-04 14:06:16.888. That tells
you which set of stack traces you're interested in within the "LAST
ANR" section of the bugreport. Find the system_server stack dumps
that were captured at the time of the watchdog's message. For
example, in the bugreport that my example came from, the "LAST ANR"
section was headed:
------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2011-04-04 14:06:14) ------
and the file holds *two* sets of system_process stacks. One of them
starts like this:
----- pid 885 at 2011-04-04 14:05:42 -----
Cmd line: system_server
and the second starts like this:
----- pid 885 at 2011-04-04 14:06:12 -----
Cmd line: system_server
Note that the first was taken 30 seconds before the second, and the
second was just a few seconds before the watchdog message about
killing the system process to restart the system. The watchdog takes
a thread snapshot after 30 seconds of the looper being unresponsive,
then another snapshot after a full minute of unresponsiveness; and
it's after that full minute that it declares the deadlock and restarts
everything. You probably want to start with the later thread stacks,
the ones that reflect the state of affairs when the watchdog finally
gave up.
In most Android applications the primary looper thread is called
"main", but this is *not* true of the system_process. The primary
system_process looper thread is titled "android.server.ServerThread".
Find that thread's stack trace that was taken at the time the watchdog
declared the deadlock, and you'll be off and running as far as
diagnosing what has caused that looper thread to be unresponsive for >
60 seconds.
At this point you've got the information you need to figure out what
locks are being contended for, what unapproved long-running operations
might be mistakenly being run on the system process's main looper,
etc. Dalvik's stack dump output is very useful, especially since it
tells you things like which other thread currently holds a lock being
requested.
Finally, so it's not my custom rom that cause random reboots to some users.
The strange thing is that not everyone get this issue, me for example, have not none a reboot since i've flashed it.
Daniel, did you have this problem in pure stock jq3?
Meant without overcome kernel installed.
Anyway, you should have this issue with jq4 too, since there are less differences between both versions.
daniel.weck said:
I'm not sure how to Heimdall-flash the JQ4 PDA tar over the ext4 partition? (since I installed Overcome, which aggressively converted /system and /data from RFS to EXT4 without any user-prompt).
Click to expand...
Click to collapse
Ok, that was simple: I flashed [factory.rfs] from JQ4 using Heimdall without repartition (and with the usual PIT file), and on reboot the Overcome kernel automatically converted to EXT4 once again (a short 2 minutes process, as my /data partition had already been converted before). The APKs are now being Odex'ed (Dalvik cache reset)...waiting...
I hope this will fix the reboot issue. UPDATE: no
af974 said:
Finally, so it's not my custom rom that cause random reboots to some users.
The strange thing is that not everyone get this issue, me for example, have not none a reboot since i've flashed it.
Daniel, did you have this problem in pure stock jq3?
Meant without overcome kernel installed.
Anyway, you should have this issue with jq4 too, since there are less differences between both versions.
Click to expand...
Click to collapse
As soon as I installed stock JQ3, I had a couple of reboots, however the ROM "became" stable rapidly and I enjoyed using the Tab for a number of days without any major issues. All this time, I was using Koxudaxi's build (overclocked, undervolted). Today, I updated some apps using the Market, I launched ezPDF and the system then entered this reboot frenzy! I went into flight mode to eliminate potential wifi/radio issues, I removed the overclocking/undervolting, and finally I switched to the Overcome kernel (just to try something different)...to no avail.
I have now flashed JQ4 [factory.rfs], but the system is rebooting again. Frustrating!!
I'm going through /data/anr/traces.txt again, hoping to find the culprit...
I was running stock froyo for the longest time, almost a year. I had huge problems with random reboots. Typically two-three days with frequent reboots followed by a week or two with few or no reboots.
I related the reboots mostly to two different things.
One was sim related and even though I had a new simcard I eventually had to get a new. I've also read about other tabowners with similar problems so maybe tabs are "simsensitive". With the new simcard, this problem went away.
The other problem was with wifi.
The easiest way to make my tab find my wireless quickly, was to put it into flightmode and back on again immediately. In 30-40 percent of the cases this would cause it to crash and reboot. After the reboot everything was fine again.
A month ago I finally dared to flash and I've been on the latest Overcome for a month now. I've had just a single random reboot in this time.
Just my two cents...
The issue appear indeed in the two versions of the ROM, the jq4 also have this issue and tweaking the build.prop does not change it, af974 I've try you're patch but still the issue remains, what is weird is that I spend the last 10 hours on wifi with no reboot and this morning, boom, reboots... the networks is not the same but still...
SOLVED.
UPDATE: [SOLVED] the reboots stop once the MicroSD card is removed from its slot. I have also tried to remove the SIM card. As soon as the SD card is inserted, the Apps2SD applications are analysed by the Nazca/Media Scanner and from this point onwards the Package Manager sub-system goes crazy. I will restore my apps on the device, and I will format the MicroSD, again... I doubt it is a problem with the Micro-SD hardware itself, more like a driver issue. It seems quite common with mobile phones, all brands concerned.
Nice one Daniel,
let us know how it goes after some test in the meantime i'll point my users to here.
daniel.weck said:
UPDATE: [SOLVED] the reboots stop once the MicroSD card is removed from its slot. I have also tried to remove the SIM card. As soon as the SD card is inserted, the Apps2SD applications are analysed by the Nazca/Media Scanner and from this point onwards the Package Manager sub-system goes crazy. I will restore my apps on the device, and I will format the MicroSD, again... I doubt it is a problem with the Micro-SD hardware itself, more like a driver issue. It seems quite common with mobile phones, all brands concerned.
Click to expand...
Click to collapse
Additional note: the MicroSD is perfectly stable when connected in USB transfer mode.
I made a selective backup of important stuff from [/sdcard/external_sd/] (whilst in USB data transfer mode with my laptop), making sure to copy all the [*.asec] App2SD files from [/sdcard/external_sd/.android-secure/]. Then I formatted the MicroSD card on my laptop, and formatted again from the tablet as it detected a corrupted/damaged card (I suppose the FAT driver on the tablet is picky). I then copied the [*.asec] files back to [/sdcard/external_sd/.android-secure/] (several megabytes which I am happy not to have to download again via the Market), and the Package Manager seems pretty stable so far. Win!
I haven't put the SIM card back in yet, first I am updating my Titanium backup!
Cheers, Dan
When the MicroSD card is scanned at startup (i.e. the card is already inserted when the device starts), the MediaScanner / PackageManager analyses the card and this seems to generate a deadlock within the system_server process (.ServerThread), which results in a soft reboot. I don't know if this happens only when there are Apps2SD files (I didn't test this particular edge-case).
So, quite simply, I just insert the MicroSD card once the device is completely booted
daniel.weck said:
When the MicroSD card is scanned at startup (i.e. the card is already inserted when the device starts), the MediaScanner / PackageManager analyses the card and this seems to generate a deadlock within the system_server process (.ServerThread), which results in a soft reboot. I don't know if this happens only when there are Apps2SD files (I didn't test this particular edge-case).
So, quite simply, I just insert the MicroSD card once the device is completely booted
Click to expand...
Click to collapse
I don't use App2sd so maybe that's why I don't have reboots with Gingerbread.
There are actually people who think that I with my SG Tab am jealous of their ipads. Moahaha!
What I did.....
What I did, when I first read this thread, I removed my SD-Card and formated it adapted to my PC (FAT32).
Next I reincerted it to my Tab. Til now (32 hours) it didn't reboot an single time:
I can check this, because of my Plantronics Discovery 975 BT headset that is permanently connected to the Tab.
Whenever in the past the Tab did a soft reboot (JQ3) it was hard work to get the headset reconnected.
PS: Used wifi for about two hours today. Seems to by stable for now. Will push some apps2sd and so on to see if it takes over rebooting.
Unfortunately I doubt this is the solution, the reboots remain even when I remove my sdcard...
CarpeNoctem said:
Unfortunately I doubt this is the solution, the reboots remain even when I remove my sdcard...
Click to expand...
Click to collapse
UPDATE: sometimes the reboot occurs even when I insert the MicroSD card after boot, so the deadlock is not completely unavoidable. However, if I long-press the search button, the system doesn't respond which generates a Force Close popup dialog for "Android System" => if I force-close this process, then the device starts responding again and everything works as normal!
daniel.weck said:
UPDATE: sometimes the reboot occurs even when I insert the MicroSD card after boot, so the deadlock is not completely unavoidable. However, if I long-press the search button, the system doesn't respond which generates a Force Close popup dialog for "Android System" => if I force-close this process, then the device starts responding again and everything works as normal!
Click to expand...
Click to collapse
Not really satisfying!
CarpeNoctem said:
Unfortunately I doubt this is the solution, the reboots remain even when I remove my sdcard...
Click to expand...
Click to collapse
Yes, same with me. Really annoying.
And by the way: android browser task often crashes, when trying to open an additional tab.
Oh damn, i really would like to have too this annoying bug.
In % , this happens in what situations? Browsing, wifi, any addictional info please.
Could someone with this bug post a logcat? Dowload alogcat from market, enable to view only errors and export the log, i don't have any reboots but my log show many errors regarding mtp, keyboard and sensor.

GT540 market and system fault

Hey guys,
i know you won´t like to hear that question, but I am trying to fix that issue for 2 days now but nothing works.
At first, I don´t know too much about all that stuff, but I tried to flash another ROM on my GT540 anyway. Obviously that didn´t work out to good.
The last ROM i flashed on my phone was V20B_00.kdz. I also reset it numerous times. I tried to use different usernames to log in to my google account at the phone. However, when I start the phone I get the fault
"System UIDs Inconsistent: UIDs on the system are inconsistent, you need to wipe your data partition or your device will be unstable. >> I´m feeling lucky"
When I click "I´m feeling lucky" I get the next fault
"Sorry! The application Market (process com.android.vending) has stopped unexpectedly. Please try again. >> Force close"
I get the second fault every time I try to start the Market. A market update didn´t work. I installed an alternative Market, still get the same fault. When I try to download the apps at my Laptop and put it on my SD card of the phone to install it, I get the fault
"Parse Error. There is a problem parsing the package. >> OK"
I tried to install an App to fix that first fault. I think it was ROM_Manager_5.0.0.1. But I get that Parse fault.
I might have changed the memory space for the system with one ROM that I had flashed to the phone. I am not sure about it. I have seen that this might be an issue for some system apps when the system partition would be too small.
I also updated my phone with LG Mobile Support Tool. So I flashed it, reset it, updated it, and now have no idea what do to, as I am not the biggest expert in that.
Help would be great. Thank you.

M8 Camera+Flash doesn't Work - Stopped Unexpectedly

Hello,
I'v searched this error many times and I have tried all the troubleshooting steps suggested, but still I'm unable to get the Camera / Flash working. While I'm writing this thread, I'm doing a hard reset to the device perhaps the first time didn't work correctly.
I'm surprised that the camera doesn't work, but when I launch WhatsApp application, I'm getting like partially of the cam works only if there's some lights.
Whenever I start the Camera App, it gives me an error Camera Stopped Unexpectedly. Report the error to HCT.
I have also tried the diagnostic code #*#*3424#*#* but that didn't help neither.
Appreciate your suggestion.
Regards,

[Help] Stock S9 stuck in bootloop

SOLVED - Update below.
Hey guys,
I have an S9 (SM-G960F) which appears to have auto-updated during the night and as a result will now not boot. I am making an assumption it was an update of some sort as when I checked the time on it at 1am it was fine, when I woke around 8.30am the phone was off and when powering it on I ran into the issue. To summarise, I power the device on, get the Samsung loading screen, then the black swipe pattern screen to decrypt the phone, followed by the padlock unlocking loading screen, then the phone reboots. Sometimes however, the device gets past the padlock loading screen and says it is optimising apps, which is then followed by a reboot, briefly says it is installing system update before landing me at the Android Recovery screen.
What I've tried:
- Soft reset
- Booting in safe mode (same result as booting normally)
- Clearing cache partition
- Clearing app data
- Lacking storage booting (the device was quite low on storage last time I checked)
Some other (maybe) useful info:
I haven't updated the phone for months, could be why it did an auto update.
I'm on EE in the UK but IIRC the phone is not locked to EE.
Android Recovery has the following info when I load into it
Code:
samsung/starltexx/starlte
9/PPR1.180610.011/G960FXXU2CSB9
(options to try again, erase app data, power off, view rescue log)
#Reboot Recovery Cause is [system_server:12259 RecoverySystemRescueParty]#
Support SINGLE-SKU
Block-Based OTA
Supported API: 3
Viewing the rescue log presents me with a stacktrace , the top of which is
Code:
*** FATAL EXCEPTION IN SYSTEM PROCESS: main
java.lang.RuntimeException: Failed to create service com.android.server.job.JobSchedulerService: service constructor threw an exception
(followed by the rest of the stacktrace I can get a picture of if necessary)
My goal here is to recover the photos on the internal storage as they don't appear to be backed up to Google photos, nor Samsung's alternative - which is particularly painful cause I'm the one usually preaching backups.
Is there anyway to recover the OS to retrieve data, or pull the data off the device without wiping it? I'm open to any suggestions on how to do this, the main goal here is saving my photos, hence why I have avoided a factory reset from the Android Recovery menu.
Hope I've been clear enough, but let me know if I need to clarify anything. I would greatly appreciate any suggestions!
Thanks,
Matt
Hey guys,
After spending all day tearing my hair out with this I managed to fix it, so I guess this thread can be closed. For anyone who gets into a similar situation...
I attempted to solve this by flashing the current firmware using Odin and booting into "download mode", found a copy on sammobile.com. This didn't work, leaving me in the same situation, and as I felt I was running out of options I tried using the latest firmware for my device. I found a copy using a tool I found on these forums - Frija. Fired up Odin and download mode again, selected the AP/BL/CP/HOME_CSC (I understand using HOME_CSC is important so as not to cause a factory reset) and this worked! This left all of my files intact and as a bonus I'm also up-to-date with Android too. I'm backing up my photos as we speak as I would hate to be in this situation again!
Hope that can help someone in the future.
Cheers,
Matt
Which version of Odin did you use?
majormatt said:
Hey guys,
After spending all day tearing my hair out with this I managed to fix it, so I guess this thread can be closed. For anyone who gets into a similar situation...
I attempted to solve this by flashing the current firmware using Odin and booting into "download mode", found a copy on sammobile.com. This didn't work, leaving me in the same situation, and as I felt I was running out of options I tried using the latest firmware for my device. I found a copy using a tool I found on these forums - Frija. Fired up Odin and download mode again, selected the AP/BL/CP/HOME_CSC (I understand using HOME_CSC is important so as not to cause a factory reset) and this worked! This left all of my files intact and as a bonus I'm also up-to-date with Android too. I'm backing up my photos as we speak as I would hate to be in this situation again!
Hope that can help someone in the future.
Cheers,
Matt
Click to expand...
Click to collapse
I would really appreciate it if you post a YouTube tutorial on how to fix this. Because we are facing the same problem right now but I have no idea what solution you prescribed. Thank you and God bless.

Categories

Resources