[Galaxy S II Original Android Development] HardCorePawn:
Damn you Lars... stop getting up so early and beating me to the punch! :p

Guys... by all means... feel free to discuss the weekly builds in here.. we are treating it as a kind of a public test... much like the CM Nightlies... just don't expect us to rush out fixes if something breaks ok? Our standard solution to any really massive issue will be "Flash the latest stable build"... ;)

However, don't be afraid to post logcats for issues that you find... as Lars has mentioned, these will assist us in finding and fixing issues before we put out the next stable release :good:

Don't play this game much... I'd guess that the latest update has changed something (most probably to fix something reported on another device) that is disagreeing with the SGS2 and/or the Mali drivers etc... :(

have you tried going into the "Recent Apps" (long press home button) and killing all apps before running Candy Crush?

Yeah... I know you were just trying to be helpful...

Anyway... it seems you are not alone... It would appear that this is an AOSP issue... :(

The weird thing is, I've trawled the code... and can't even find this DictionarySettingsFragment that is spitting out the: "E/DictionarySettingsFragment(30964): Could not find the preference for a word list id main:nl" error that seems to be the cause... I'm guessing it is downloading the dictionary, but has no preference to attach it to... hence the "E/BinaryDictionaryFileDumper(2368): Could not copy a word list. Will not be able to use it." error... :confused:

I think this is a function of the somewhat "hackish" nature of the hardware drivers for the SGS2... ironically enough, while researching this issue, I found lots of people complaining that their phone (note: this was on other devices, not SGS2) only plays alarms through speaker, so when they're on public transport with headphones in, they get dirty looks :p

Another interesting "feature" I found, is that if you plug headphones in... if an alarm goes off BEFORE any other sound is played... it will come out the speaker rather than the headset... however as soon as any sound (ie. dialer, media player etc) is played through headset, from that point on, alarms will come out headset (until headset is removed)... you can test this by:

Alarm out Speaker with Headset in:

1. set alarm for 1 minute from now

2. plug in headset

3. wait...

4. alarm comes out speaker!!?!

Alarm out Headset:

1. set alarm for 1 minute from now

2. plug in headset

3. quickly play a couple of seconds of music

4. wait...

5. alarm will now only come out headset

Anyway, looking through logcats, it seems that if you plug in a headset, the phone initially tries to play the alarm through device "6"... which apparently doesn't exist, as I can see error messages saying as much in logcat... as near as I can figure... the devices are:

1: earphone (ie. internal "phone" earpiece)

2: external speaker

3: wired headphone

4: wired headset (ie. headphone with mic)

It then searches for an available audio routing, finds "4" (or "3" depending on type of headset) and routes the audio through that... hence why the audio comes out the headset

Now... I'm not sure if I'll be able to solve this... as this is all happening in the low level C code in TinyALSA Audio drivers etc... and I can't even locate where/how it is being called... so I can't figure out where this "routing=6" value is coming from... :( I suspect it is all tucked away in the kernel somewhere... which is a giant mystery to me :confused:

I tried modifying the TinyALSA-config.xml to include 2 extra devices (dummy and a "both") so that hopefully routing=6 would try to output to both speaker and headset, but it didn't work... it just said "invalid device = 0x6" like it always does :(

So I'm guessing the declaration of devices is hidden somewhere else... I'll keep looking, but don't expect anything in the near future... :(

It is because our default DPI is 182... if you go to Settings -> Interface -> General -> LCD Density... you can reset it to the default 240...