Database Users

WARNING messages created byROM kitchen log files

I have been playing around in the kitchen the past days and managed to cook several 'version' of ROMs. Each always produced the same error message, as below:
echo Warning: OS type not detected, you may need to set tounicode variable manuallywrite xip block starting at 81740000, with 7 fileswrite xip block starting at 81b00000, with 122 files!!! your rom is not known to me: md5: 1cd007bbffa268b12b7968cabb7cc75fthis bootloader seems to be V5.22 2003-05-15 17:46:55no operator rom found80000000 - 80040000 -- bootloader 0 files 1 modules80040000 - 8015d5cc 9 XIPKERNEL 5 files 5 modules80180000 - 80375bdc 8 KERNEL 10 files 14 modules80380000 - 8064306c 7 OS 20 files 36 modules80670000 - 80be66a8 6 SHELL 107 files 88 modules80c00000 - 8102ce98 5 BROWSING 11 files 36 modules81050000 - 813ef114 4 COREAPPS 95 files 44 modules81400000 - 815d2238 3 EXAPPS 34 files 7 modules815f0000 - 8171bc7c 2 PHONE 56 files 19 modules81740000 - 8177ffec 10 XDA_DEVELOPERS1 7 files 0 modules81780000 - 81781c34 -- xip chain 11 xip entries817c0000 - 81ae4338 1 MISC 109 files 42 modules81b00000 - 81e1904c 11 XDA_DEVELOPERS2 122 files 0 modules81ec0000 - 81ee5800 -- bitmap : ffffffff .. ffffffff../rom.exe: found a preamble of 31232 bytes adding: English/NK.nbf (deflated 47%)
-------------------------------------------
Does it mean anything? Is this normal?
I have used one of the newly created ROM and installed it in my XDA. The installation went smooth. But now after 12 hours usage my XDA run unusually sluggish...i.e. when I tapped a menu, the response took a good 3 secs or even much longer on some menus...
I just did a hard reset and everything seemed to be fine (for now), but now I am concerned if this thing will happen again.
Has anyone experienced this before? Could any one please be so kind as to give me a short explantion?
BTW, this website is the coolest thing I have ever experienced in my 17 years of internet browsing. Simply the best!!

I have experienced similar warning msgs on the logs. I think they are pretty normal, but the ROMs work fine.
Abt the slow response - I had similar problems with my device initially. After lots of research, I found that the problem was the stk.lnk file in the startup folder. Once I removed this, all was fine.
The ROM kitchen does this for you now.
Also select "fix multiple reset bug .. " as well.
hope this helps

Ignore this warning. It just means the 4.x ROMs aren't in the database of known ROMs yet. Lazyness on our part...

sps: appreciate your kind reply and advises. Did all that ...actually ..
another small problem I just found when i turned on the unit, the xda started a soft reset automatically (i.e. i did not press the soft reset button at all). On another occasion, the unit went off as soon as the back light went off. (my battery was fully charged).
sorry if i asked too many small questions like this, but i wanted to know if anyone else experienced these and that if it is some bugs from WM2003 or something else. I don't mind with all these teething problems, as i always like to try new things. But I need some advises/ comments.
xda-developers : thank you for your prompt n effective explanation..
cheers..

Possible malicious program?

I just got a text message from T-mobile: "Free T-Mobile Msg: Your data usage in this billing cycle has exceeded 10 GB;Data throughput for the remainder of the cycle may be reduced to 50 kbps or less"
I heavily use the internet capabilities on this phone, but I've never exceeded 1.5 GB in the months were I've looked at my usage, so I guessed that something was going on that I didn't know about.
The first thing I did was check data usage on T-Mobile's website. Stretching as far back as the usage history goes (7/28), I'm seeing fairly large chunks of data usage, even in the middle of the night when I'm certainly not using the phone. ex:
07/28/09 05:21 AM 8.6367
07/28/09 05:16 AM 29.3007
07/28/09 05:12 AM 9.7666
07/28/09 03:12 AM 8.6728
07/28/09 03:01 AM 39.0654
07/28/09 01:01 AM 8.6533
07/28/09 12:53 AM 39.0654
Something is either malicious or has a serious bug.
I'm not quite sure how to debug this. I've switched it over to my wifi network. I think I can install tcpdump on my router and at least see what the phone is sending and where.
Has anyone had a similar problem? Check your data usage on T-mobile's website. I don't know how long this has been going on before it managed to trip their 10 GB threshold.
Here is a list of the installed programs on my system. If anyone can check their usage and tell me that they have x program and definitely aren't having any problems, that would be helpful.
JF ADP 1.5 ROM as the base
/data/app:
android.game.doom.apk
com.akproduction.notepad.apk
com.alex.PodcastManager.apk
com.alfray.bearing.apk
com.amazon.mp3.apk
com.android.BetterBookmarks.apk
com.android.wallpapersetandsave.apk
com.androidemu.snes.apk
com.ap.DroidFtp.apk
com.app.webcamwidgetca.apk
com.appdroid.anycut.apk
com.appdroid.videoplayer.apk
com.aws.android.apk
com.bg.smsbk.apk
com.bigtincan.android.adfree.apk
com.billnapier.android.livebookmarks.apk
com.compareeverywhere.apk
com.cooolmagic.android.toggle5.apk
com.deafcode.android.Cinema.apk
com.deafcode.android.Orienteer.apk
com.eclipsim.gpsstatus2.apk
com.eri.widget.binaryclock.apk
com.estrongs.android.pop.apk
com.farproc.wifi.analyzer.apk
com.flashcup.apk
com.g3.android.widgets.sdcardm.apk
com.google.android.apps.maps.apk
com.google.android.maps.mytracks.apk
com.htc.pdfreader.apk
com.isaacwaller.youtubedownloader.apk
com.lindaandny.lindamanager.apk
com.mibollma.wakemeR1.apk
com.nextmobileweb.quickpedia.apk
com.paxmodept.palringo.android.main.apk
com.roundedlabs.widgets.Brightness.apk
com.roundedlabs.widgets.Ringer.apk
com.roundedlabs.widgets.Wifi.apk
com.roundedlabs.widgets.bluetooth.apk
com.schwimmer.android.mmsextract.apk
com.schwimmer.android.togglebluetooth.apk
com.schwimmer.android.togglebright.apk
com.schwimmer.android.togglegps.apk
com.schwimmer.android.togglewifi.apk
com.shazam.android.apk
com.streamfurious.android.free.apk
com.taskManager.rootTaskManager.apk
com.tmobile.selfhelp.apk
com.tni.TasKiller.apk
de.android_telefonie.appmanager.apk
droidsans.android.DroidSansTweakToolsLite.apk
fm.last.android.apk
info.marcelp.android.locmark.apk
jp.co.taosoftware.android.widget.calendar.apk
jp.co.webimpact.ty.darairc.apk
lysesoft.andexplorer.apk
net.androidcomics.acv.apk
net.ser1.timetracker.apk
nl.jsource.retroclock.android.apk
nl.rogro.GScript.apk
nl.rogro.GScriptLite.apk
org.connectbot.apk
org.microemu.android.Browser.apk
org.rabold.android.wifibuddy.apk
rip.android.GlImageView.apk
tw.mawa.jasoncheng.aNetShare.apk
/data/app-private:
com.agilesoftresource.apk
com.ap.SnapPhoto_Pro.apk
I would also guess that with this being the first month to trip 10 GB that it is something that got installed last month (and possibly updated at some point), so I'm a little more suspicious of those. Here are the programs with modify dates from July and August:
Jul 28 23:39 com.akproduction.notepad.apk
Jul 26 13:47 com.alfray.bearing.apk
Jul 22 20:48 com.app.webcamwidgetca.apk
Jul 15 00:03 com.billnapier.android.livebookmarks.apk
Jul 22 20:44 com.google.android.apps.maps.apk
Jul 18 15:12 com.google.android.maps.mytracks.apk
Jul 3 13:05 com.shazam.android.apk
Jul 10 19:26 jp.co.taosoftware.android.widget.calendar.apk
Jul 17 00:12 net.androidcomics.acv.apk
Jul 1 00:00 org.connectbot.apk
Aug 1 16:56 com.androidemu.snes.apk
Aug 14 01:21 com.ap.SnapPhoto_Pro.zip
Aug 5 17:50 com.bg.smsbk.apk
Aug 14 11:58 com.bigtincan.android.adfree.apk
Aug 14 11:58 com.estrongs.android.pop.apk
Aug 14 01:20 com.farproc.wifi.analyzer.apk
Aug 5 04:00 com.streamfurious.android.free.apk
Aug 14 01:23 com.tmobile.selfhelp.apk
Aug 5 17:49 com.tni.TasKiller.apk
Aug 12 01:15 de.android_telefonie.appmanager.apk
Aug 5 13:44 fm.last.android.apk
Aug 5 22:23 jp.co.webimpact.ty.darairc.apk
Aug 6 03:41 lysesoft.andexplorer.apk
Aug 9 20:03 org.rabold.android.wifibuddy.apk

Why dont you try using the spare parts app and seeing what in network is using up the most battery? that could probably tell you whats using the most data. Also try installing droid wall and setting it to use only apps that you want to access data

Ahh, I hadn't really looked at spare parts beyond turning on the maps compass.
Battery History / Network usage shows Media as a major hog with 1,451,82,439 bytes received since last boot. Last boot time was mid-day last Friday.
"Packages sharing this UID:
Camera
DRM Protected Content Storage
Download Manager
Media Storage"
Hmm, all of those sound like Google packages. Not sure what to think here.

Download manager is probably the one.
Are you sure you are using JFADP1.5 and not JFtmobile1.5? The latter will continuously try to download OTA updates and repeatedly fail, which would account for the data usage.
tiberiumx said:
Ahh, I hadn't really looked at spare parts beyond turning on the maps compass.
Battery History / Network usage shows Media as a major hog with 1,451,82,439 bytes received since last boot. Last boot time was mid-day last Friday.
"Packages sharing this UID:
Camera
DRM Protected Content Storage
Download Manager
Media Storage"
Hmm, all of those sound like Google packages. Not sure what to think here.
Click to expand...
Click to collapse

Settings->About Phone shows Model number as "Android Dev Phone 1", and I install JF1.5 as soon as it was available (I think the t-mobile one came later).
How does the JF rom avoid downloading the updates?
I have the adblock program, which modifies /etc/hosts. Maybe JF was intended to block this function via the hosts file but that got overwritten?
Did T-Mobile release an update last month?

Okay, so I found a tcpdump binary for Android and ran it on my phone last night.
Looks like all of the traffic is due to the downloading of an update.
I see several HTTP GETs to android.clients.google.com:
"GET /updates/signed-kila-ota-150275.53dde318.zip HTTP/1.1\r\n
Host: android.clients.google.com\r\n
User-Agent: AndroidDownloadManager\r\n"
I checked out the JF1.5 update.zip and saw an empty hosts file, so this isn't how it avoids updating. This also wouldn't be a good idea -- and cannot be the solution to my problem -- because it also appears to sync email/etc from this server (I see fairly frequent SSL connections opened to this host).
How would it normally refrain from downloading the update with JF1.5?
Any ideas on how to fix this?
The update downloads to /cache/update.zip, correct? Perhaps I could just create a root-owned read-only update.zip in /cache and it would fail with a "cannot open file" error when it tried to write.

There is a trick to this...
not finding it right now but I know there's something fairly easy you can do to keep this issue from occurring. I'll dig deeper.

tiberiumx said:
Settings->About Phone shows Model number as "Android Dev Phone 1", and I install JF1.5 as soon as it was available (I think the t-mobile one came later).
Click to expand...
Click to collapse
That doesn't mean anything.

tiberiumx said:
Okay, so I found a tcpdump binary for Android and ran it on my phone last night.
Looks like all of the traffic is due to the downloading of an update.
I see several HTTP GETs to android.clients.google.com:
"GET /updates/signed-kila-ota-150275.53dde318.zip HTTP/1.1\r\n
Host: android.clients.google.com\r\n
User-Agent: AndroidDownloadManager\r\n"
I checked out the JF1.5 update.zip and saw an empty hosts file, so this isn't how it avoids updating. This also wouldn't be a good idea -- and cannot be the solution to my problem -- because it also appears to sync email/etc from this server (I see fairly frequent SSL connections opened to this host).
How would it normally refrain from downloading the update with JF1.5?
Any ideas on how to fix this?
The update downloads to /cache/update.zip, correct? Perhaps I could just create a root-owned read-only update.zip in /cache and it would fail with a "cannot open file" error when it tried to write.
Click to expand...
Click to collapse
As I said before, you have tmobile software installed and it is continually downloading updates.

tiberiumx,
This is a known issue with some JF 1.5 ROMs. Here are some fixes from JF's android blog at http://jf.andblogs.net/:
1. delete the otacerts.zip file manually. The file is at /system/etc/security/otacerts.zip But keep in mind if you use this method your phone will continuously re-down the OTA and try to verify it, which is bad on your bandwidth usage and your battery life
2. Replace /system/build.prop on your phone with the one from the ADP1 version of JFv1.51
3. chmod 000 the OTA file in /cache (unconfirmed solution, but is likely to work)

tiberiumx said:
Okay, so I found a tcpdump binary for Android and ran it on my phone last night.
Click to expand...
Click to collapse
Hi,
I'm looking for a tcpdump for android: can you tell me where you have found it?
Thanks
Louis

[GUIDE] My Bell Canada flashing/rooting procedure

Update: I upgraded my phone with XXKI3 2.3.5 firmware, from XXKH3.
The lag is gone, definitely a big improvement compared to XXKH3 version. The phone is very responsive and fast. Quadrant shows 4200+, pretty impressive:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The bootloader was updated, you cannot reset anymore your phone with a download jig. However, Intratech uploaded the old bootloader:
Intratech said:
If you've already flashed a full package from elsewhere and cannot reset your binary counter using the Jig just flash this package in the PDA or Bootloader (Yes both will work) section of Odin to replace the bootloaders and then you can reset the counter: http://www.multiupload.com/LQQBRQVJUD
Click to expand...
Click to collapse
Personally, I flashed the file with Odin (PDA).
The phone ring is set to silent, instead of default "Over the horizon" ringtone. Make sure you change it, your phone is not broken. See the complete list of changes, related to previous ROM.
Guide
I'm posting this procedure in a separate thread, as is easier to be linked into different forum posts. My Bell Canada phone came originally with the UGKG2 firmware, so everything listed below is based on my own experience with this version, I do not know or confirm it will work with other firmware. I currently run the official (?) XXKI3 Gingerbread 2.3.5 firmware, downloaded from samfirmware.com site (see details below). This is a wipe device release.
Personally, I read that other people flashed their phones with a different firmware... but I did not wanted to do it on my phone. I sticked with the same family XXKGx, just to be safe. Please read Electroz's explanation below.
There are 3 types of release builds: leaked, Frankenstein (compiled and tested by devs, based on demand) and official (Kies updates).
The procedure is simple (I presume you are familiar with Odin, Download Mode &Co.):
1) Get yourself the stock firmware and kernel (thank you Intratech)
2) Setup your drivers properly, avoid the Kies insanity (see below)
3) Flash the new firmware (my flash procedure, you can/should skip Re-Partition/PIT as Intratech explained)
4) Flash phone with CF-Root (I used the CF-Root-SGS2_XX_OXA_KI3-v4.1-CWM4.zip file)
5) Wipe (cache + factory reset)
6) Uninstall all Samsung crap and install additional system apps (i.e. Car Home)
7) Flash back the stock KI3 kernel (thank you Intratech, password: [email protected])
8) Wipe (cache + factory reset)
9) Connect your device to a download jig, to reset the flash counter (old bootloader needed)
Phone & Modem Drivers Setup
Note: This procedure was tested with Windows 7 Ultimate 64bits. If you already installed Kies, uninstall all related software/drivers and clean your registry. Or do a clean Windows install just to be safe.
1) With your anti-virus off, put your phone in Download mode and connect the USB cable. Windows Update will start to download right away the modem and USB drivers. Make sure you select the Windows Update option, when asked into driver install window.
2) Once the modem drivers installed, disconnect the cable, reboot the phone in normal mode and reconnect the cable again. A new set of drivers will be installed for the rest of USB interface.
Important: You need do it in the SPECIFIC order mentioned above, or else the modem drivers will not be installed and you will not be able to use properly Odin. I know this because I tried the other way around.
Initial Phone Setup
Once the phone rebooted, you will be welcomed to the Android Setup.
1) First, set the language from English UK to whatever you like.
A Network warning related to Date and Time will pop, tap on Cancel.
2) Tap the Android robot and setup your phone.
There is NO need to change any other settings, the phone will automatically detect the Bell network.
If for some reason it does not, once you completed your basic setup go to:
Settings > Wireless and Network > Mobile networks > Network operators
It will start the scanning and pop 3 Bell networks, pick the first one. Again, this is in case your phone does not work with calls, voicemail or SMS.
Notes
You should uninstall the CWM app once you flashed back the stock kernel, is half useless. I tested the new Superuser app from Android Market, it will properly upgrade to latest version and also upgrade the su binary on XXKI3 firmware. If you plan to poke around your phone with the Terminal, you will lose all the fancy Linux commands. (grep etc.)
Personally, I purchased ChainsDD's Superuser Elite key. It will allow you to pin protect your rooted device, among other useful things that are planned to be added (built-in terminal). I upgraded Superuser to version 3 and everything works properly.
Battery Power Savings
I always leave my phone with all default options, including screen auto-adjust. The only options I turn off are:
Settings > About phone > Software update > Auto update Disabled
Settings > Applications > Samsung Apps > Off
Personally, I have no idea who started the battery calibration myth in S2. It is useless to "overcharge" the battery, as the software has a check to stop automatically the charge once the battery is 100% while the battery itself has a build-in controller that can't be wiped.
Example of battery stats with the phone in idle mode for approx. 18hrs (86%) and 109hrs (2%):
Running Services
I use Wifi N with a Cisco E4200 DD-WRT (phone at 20"), these are my running services:
Code:
PID USER VSZ STAT COMMAND
1 root 508 S /init
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [migration/0]
5 root 0 SW [watchdog/0]
9 root 0 SW [events/0]
11 root 0 SW [khelper]
15 root 0 SW [async/mgr]
16 root 0 SW [pm]
19 root 0 SW [suspend]
20 root 0 SW [sync_system_wor]
151 root 0 SW [s5p-tmu]
337 root 0 SW [sync_supers]
339 root 0 SW [bdi-default]
341 root 0 SW [kblockd/0]
356 root 0 SW [khubd]
359 root 0 SW [kseriod]
394 root 0 SW [irq/331-max8997]
434 root 0 SW [kmmcd]
527 root 0 SW [kondemand/0]
540 root 0 SW [pet_watchdog/0]
549 root 0 SW [khungtaskd]
550 root 0 SW [kswapd0]
599 root 0 SW [aio/0]
612 root 0 SW [crypto/0]
1237 root 0 SW [sec_jack_wq]
1240 root 0 SW [irq/350-sec_hea]
1245 root 0 SW [spi_gpio.3]
1262 root 0 SW [svnet_txq]
1274 root 0 SW [file-storage]
1300 root 0 SW [irq/328-mxt224_]
1306 root 0 SW [irq/325-k3g]
1312 root 0 SW [irq/326-proximi]
1315 root 0 SW [cm3663_light_wq]
1316 root 0 SW [cm3663_prox_wq]
1366 root 0 SW [mali_dvfs]
1369 root 0 SW [mali-pmm-wq]
1378 root 0 SW [sii9234_wq]
1379 root 0 SW [irq/481-mhl_int]
1380 root 0 SW [irq/496-mhl_wak]
1383 root 0 SW [irq/343-max1704]
1394 root 0 SW [kstriped]
1396 root 0 SW [kmpathd/0]
1398 root 0 SW [kmpath_handlerd]
1399 root 0 SW [ksnapd]
1400 root 0 SW [kconservative/0]
1414 root 0 SW [ktflash_requlat]
1429 root 0 SW [usbhid_resumer]
1432 root 0 SW [binder]
1441 root 0 SW [irq/333-IPC_HOS]
1452 root 0 SW [mmcqd]
1481 root 0 SW [l2cap]
1482 root 0 SW< [krfcommd]
1488 root 0 SW [dynamic hotplug]
1501 root 0 SW [melfas_touchkey]
1506 root 0 SW [fimc0_iqr_wq_na]
1509 root 0 SW [fimc1_iqr_wq_na]
1512 root 0 SW [fimc2_iqr_wq_na]
1515 root 0 SW [fimc3_iqr_wq_na]
1518 root 0 SW [hdcp work]
1529 root 0 SW [tvout resume wo]
1535 root 0 SW [sec-battery]
1538 root 384 S /sbin/ueventd
1761 root 0 SW [Si4709_wq]
1782 root 0 SW [jbd2/mmcblk0p9-]
1784 root 0 SW [ext4-dio-unwrit]
2563 root 0 SW [jbd2/mmcblk0p7-]
2564 root 0 SW [ext4-dio-unwrit]
2566 root 0 SW [jbd2/mmcblk0p1-]
2567 root 0 SW [ext4-dio-unwrit]
2570 root 0 SW [jbd2/mmcblk0p10]
2571 root 0 SW [ext4-dio-unwrit]
2579 system 868 S /system/bin/servicemanager
2580 root 6616 S /system/bin/vold
2581 system 1972 S /system/bin/notified_event
2583 root 732 S /system/bin/debuggerd
2584 radio 9512 S /system/bin/rild
2585 system 4624 S /system/bin/npsmobex
2586 system 8476 S /system/bin/drexe
2590 bluetoot 1372 S /system/bin/dbus-daemon --system --nofork
2591 root 932 S /system/bin/installd
2592 keystore 1804 S /system/bin/keystore /data/misc/keystore
2594 system 14192 S /system/bin/tvoutserver
2595 shell 800 S /system/bin/sh /system/bin/rtc_log.sh
2612 shell 780 S /system/bin/immvibed
2907 wifi 2644 S /system/bin/wpa_supplicant -Dwext -ieth0 -c/data/wifi/bcm_su
3374 media 56536 S < /system/bin/mediaserver
3375 root 15472 S /system/bin/netd
3376 root 126m S zygote /bin/app_process -Xzygote /system/bin --zygote --star
3391 system 276m S system_server
3496 root 0 SW [iscan_sysioc]
3497 root 0 SW [dhd_watchdog]
3498 root 0 SW [dhd_dpc]
3499 root 0 SW [dhd_sysioc]
3502 system 152m S com.android.systemui
3511 app_99 168m S com.sec.android.inputmethod.axt9
3521 radio 155m S com.android.phone
3522 app_66 148m S android.process.media
3528 app_53 134m S com.sec.pcw.device
3532 system 134m S com.samsung.bt.avrcp
3536 bluetoot 134m S com.broadcom.bt.app.system
3544 app_12 176m S com.sec.android.app.twlauncher
3604 app_54 173m S com.google.process.gapps
3631 app_12 148m S android.process.acore
3688 app_84 135m S com.sec.android.app.FileTransferManager
3777 app_36 137m S com.sec.android.widgetapp.weatherclock
3927 app_38 136m S com.sec.android.widgetapp.apnews
4193 app_91 137m S com.sec.android.app.clockpackage
4220 app_16 137m S com.android.providers.calendar
4234 app_100 134m S com.sec.android.daemonapp.accuweather
4255 app_78 159m S com.google.android.gm
4333 app_81 174m S com.cooliris.media
4366 app_119 144m S com.google.android.apps.reader
4376 app_103 170m S com.levelup.beautifulwidgets
4435 app_37 138m S com.sec.android.widgetapp.stockclock
4453 app_16 138m S com.android.calendar
4476 system 156m S com.android.settings
4486 app_112 177m S com.google.android.music
4633 app_82 137m S com.sec.android.app.fm
4752 app_40 135m S com.sec.android.app.samsungapps.una
6623 app_68 185m S < com.google.android.apps.maps
9014 dhcp 916 S /system/bin/dhcpcd -ABK eth0
10732 graphics 139m S com.sec.android.app.screencapture
11958 system 138m S com.wssyncmldm
11989 system 135m S com.sec.android.providers.drm
11997 app_1 139m S com.smlds
12037 app_102 139m S com.skype.raider
13094 app_5 141m S jackpal.androidterm
13136 app_115 135m S com.noshufou.android.su
13170 app_68 149m S com.google.android.apps.maps:NetworkLocationService
13180 app_68 144m S com.google.android.apps.maps:FriendService
13503 app_83 141m S com.sec.android.app.FileTransferServer
13579 root 0 SW [flush-179:0]
13646 shell 1684 S /sbin/ext/busybox sh /sbin/sleep 3600
13651 shell 1676 S /sbin/ext/busybox /sbin/sleep 3600
13707 app_68 154m S com.google.android.apps.maps:HotpotService
13788 system 135m S com.android.MtpApplication
13825 app_5 796 S /system/bin/sh -
13858 root 796 S sh -
13966 root 1684 S /sbin/ext/busybox sh /sbin/ps
13971 root 1716 R /sbin/ext/busybox /sbin/ps
CSC (Cell Site Controller)
The default CSC setting in XXKI3 is KOR. You can check it with: *#272*{IMEI}#
where the {IMEI} value represents the 15 digits of your IMEI (International Mobile Equipment Identity).
I personally used the default option (KOR) and the phone works perfect, with great reception:
There are some people who wonder if they should change the CSC. I will quote Intratech on this matter as he answered perfectly to my question:
Intratech said:
Some people do and some just use the CSC packaged with whichever firmware they flash. As long as your APN and SMS/MMS settings are ok there is no need to flash another CSC package.
Click to expand...
Click to collapse
Fast Dormancy
Some people noticed that their network idle on 3G, instead of HSPA+. That is absolutely normal, because of the "fast dormancy" feature. If enabled, HSPA+ will rapidly disconnect from the network once the information is sent or received. That will penalize the actual network you are on, unless the carrier network and your phone talk to each other in a way that takes battery life as well as network congestion into consideration. For this to work, both networks and smartphones have to implement a standardized version of the fast dormancy feature. Bell Canada supports this feature and by default Fast Dormancy is enabled into XXKI3 firmware.
You can check it with: *#9900#
You should call your carrier to see if they have it implemented. Probably your tech support will look like you are speaking Chinese and escalate it to a more knowledgeable guy. This is the average download speed I get on XXKI3 (network is switching automatically on HSPA+):
There are some reports where people confirmed that the UGKG2 build allowed you to reach faster download speeds (up to 9MB). Personally I think 6MB over a cell network is already more than perfect for tethering, not to mention that there are many factors to be taken into consideration when you deal with a wireless transmission. (location, tower antenna, weather, etc.)
Random Restart
The screen needs minimum 500Mhz to get out of Sleep Mode. Some custom ROM's use a low voltage or "underclock" feature that reduces the power consumption but also the number of CPU steps. That is what makes your phone crash and reboot randomly. If you use an external sdcard, do a sd wipe just to be safe. It should take several hours, so do it over the night. Personally, I did not experienced any random reboots using neither the XXKH3 or XXKI3 firmware.
Some people might have bad battery contacts on their S2. Basically, the phone shuts down while in your pocket. Clean the battery terminals with some audio head tape cleaner and cotton swabs, than make sure the contacts are proper.
You could also have a RAM (hardware) issue. Bad memory degrades fast so you will see your random reboots pop at a faster frequency. If you did all the above and still experience random reboots, run adb logcat to see what is going on at that specific moment. If you get error codes like:
Code:
code 1 (SEGV_MAPERR), fault addr 00000000
you are dealing with bad memory unfortunately and need to service your phone.
Manage system apps with Terminal
Personally, I decided to stick with a terminal for now, I feel more comfortable to see what is going on with my own eyes in my phone. A good alternative to Terminal would be the SystemApp Remover, is faster and more robust compared to Titanium Backup as it does only one task (backup/remove system apps).
I did an output list of all the packages:
Code:
$ pm list packages -f >> /sdcard/packages 2>&1
so I know now where each package is located and what is the associated name.
All I have to do is run:
Code:
$ su
# rm -f /system/app/package.{apk,odex}
# pm clear PACKAGE
# pm uninstall PACKAGE
Running "mount | grep system" tells me right away where and how /system is mounted:
Code:
/dev/block/mmcblk0p9 on /system type ext4 (ro,relatime,barrier=1,data=ordered)
so all I have to do is change the mount perms to write, instead of read:
Code:
# mount -o remount,rw /dev/block/mmcblk0p9 /system
Package Manager commands:
Code:
# pm
usage: pm [list|path|install|uninstall]
pm list packages [-f] [-d] [-e] [-u] [FILTER]
pm list permission-groups
pm list permissions [-g] [-f] [-d] [-u] [GROUP]
pm list instrumentation [-f] [TARGET-PACKAGE]
pm list features
pm list libraries
pm path PACKAGE
pm install [-l] [-r] [-t] [-i INSTALLER_PACKAGE_NAME] [-s] [-f] PATH
pm uninstall [-k] PACKAGE
pm clear PACKAGE
pm enable PACKAGE_OR_COMPONENT
pm disable PACKAGE_OR_COMPONENT
pm setInstallLocation [0/auto] [1/internal] [2/external]
The list packages command prints all packages, optionally only
those whose package name contains the text in FILTER. Options:
-f: see their associated file.
-d: filter to include disbled packages.
-e: filter to include enabled packages.
-u: also include uninstalled packages.
The list permission-groups command prints all known
permission groups.
The list permissions command prints all known
permissions, optionally only those in GROUP. Options:
-g: organize by group.
-f: print all information.
-s: short summary.
-d: only list dangerous permissions.
-u: list only the permissions users will see.
The list instrumentation command prints all instrumentations,
or only those that target a specified package. Options:
-f: see their associated file.
The list features command prints all features of the system.
The path command prints the path to the .apk of a package.
The install command installs a package to the system. Options:
-l: install the package with FORWARD_LOCK.
-r: reinstall an exisiting app, keeping its data.
-t: allow test .apks to be installed.
-i: specify the installer package name.
-s: install package on sdcard.
-f: install package on internal flash.
The uninstall command removes a package from the system. Options:
-k: keep the data and cache directories around.
after the package removal.
The clear command deletes all data associated with a package.
The enable and disable commands change the enabled state of
a given package or component (written as "package/class").
The getInstallLocation command gets the current install location
0 [auto]: Let system decide the best location
1 [internal]: Install on internal device storage
2 [external]: Install on external media
The setInstallLocation command changes the default install location
0 [auto]: Let system decide the best location
1 [internal]: Install on internal device storage
2 [external]: Install on external media
Removed System Apps
This is the list of /system apps I removed from XXKI3 firmware:
BuddiesNow.apk
Days.apk
DigitalClock.apk (I use Beautiful Widgets instead)
Email.apk (I use Gmail only)
EmailWidget.apk
GameHub.apk
GenieWidget.apk
install_flash_player.apk
Kies.apk
KiesAir.apk
kieswifi.apk
Kobo.apk
MiniDiary.apk
MusicHub_U1.apk
MusicPlayer.apk (I use Google Music instead)
PolarisOffice.apk
PressReader.apk
ReadersHub.apk
SamsungApps.apk
SamsungAppsUNA3.apk
SamsungIM.apk
SecretWallpaper1.apk
SecretWallpaper2.apk
SevenEngine.apk
ShareApp.apk
SnsAccountFb.apk
SnsAccountLi.apk
SnsAccountMy.apk
SnsAccountTw.apk
SnsDisclaimer.apk
SnsImageCache.apk
SnsProvider.apk
SocialHub.apk
VoiceToGo.apk (I use Car Home instead)
Zinio.apk
Apps ported to Galaxy S2
Some of my favorite apps, not available into Market and ported to Galaxy S2:
Google Car Home
Market Access
Google+ 2.0 (works with a Google Apps account)
Terms
ROM - software stored into read-only memory. ROM retains its contents even when the phone is turned off. ROM is referred to as being nonvolatile, whereas RAM is volatile.
Kernel - portion of the OS that handles drivers, hardware control and access for the rest of the OS.
Modem - handles the communication with your carrier.
Root - superuser privileges in any Linux OS.

yqed said:
I'm posting this procedure in a separate thread, as is easier to be linked into different forum posts. My Bell Canada phone came originally with the UGKG2 firmware, so everything listed below is based on my own experience with this version, I do not know or confirm it will work with other firmware. I currently run the official (?) XXKG3 Gingerbread 2.3.4 firmware, downloaded from samfirmware.com site (see details below).
Personally, I read that other people flashed their phones with a different firmware... but I did not wanted to do it on my phone. I sticked with the same family XXKGx, just to be safe.
Click to expand...
Click to collapse
This is wrong. I'm not sure where you got that XXKG3 is remotely the same as UGKG2, but here's an explanation of the firmware version numbers:
This is standard across most Samsung Phones.
I9000 = Model #
UG = Carrier/Area code. For example, XX = Europe, UG = Bell Mobility Canada.
K = Year = 2011
G = Month = July (H = August, I = September)
2 = Revisions that month for the specific region (aka. UG, XX, XW).
A lot of people on here think the last 3 digits are important and that if you have 2 KG3 firmware that they are the same. However, this is not the case.
You need to go by all 5 letters due to the fact that each firmware is customized by different groups at Samsung. And to prove this, just look at KG2. There are 2.3.3 KG2's and there are 2.3.4 KG2's.
It's actually possible that one area's KG2 could have been newer than another area's KG4. The best way to check, is to look at the build date in the Build.prop for each firmware.
But your assuming that KGx means they're the same is wrong. All that those numbers mean is what month/revision the firmware is. Samsung has several different teams producing firmware independently of each other for different regions. The only letters that mean the firmwares are similar are the country/carrier code (ie. UG, XX, XW).
Also, your idea of what Official firmware is, is flawed. Just because it's on samfirmware, DOES NOT make it official. Most of their firmwares are leaked test builds. If it's not released on Kies, it's not official.

Thanks for the great explanation, much appreciated. It should help many people understand better how the versioning works. About the "official" part, that's the reason why I mark it with a (?). As you said very well, it is official once is released by Samsung through updates.
The thread is related to my own experiences with the Europe MULTI firmware, based on the fact that a Bell phone specs are identical to the Europe model.
Edit: I upgraded to XXKH3 firmware successfully just now, everything works great.

I currently have a Bell branded SGSII with baseband version UGKG2.
I originally flashed it with CF-Root-SGS2_ZS_OZS_KG2-v4.1-CWM4.zip and then I re-flashed it with the original UGKG2 Stock Kernel from Bell.
Now my phone is rooted and stock.
Any positive/negative feedback from users running XXKH3 firmware (2.3.4) would be very much appreciated.

thvpham said:
I currently have a Bell branded SGSII with baseband version UGKG2.
I originally flashed it with CF-Root-SGS2_ZS_OZS_KG2-v4.1-CWM4.zip and then I re-flashed it with the original UGKG2 Stock Kernel from Bell.
Now my phone is rooted and stock.
Any positive/negative feedback from users running XXKH3 firmware (2.3.4) would be very much appreciated.
Click to expand...
Click to collapse
I ran the KH3 firmware briefly with no issues. The only annoying this was when using the program monitor widget I would experience some lag or choppiness when switching homescreens(same on KG6/KH4). On the positive side the gps accuracy and lock time was greatly improved.

Aha, I had no idea as I don't use that widget... thanks for the tip.
I usually hold the Home button until the Task Manager pops, to see the running apps. But I got used already to press the Back key every time I deal with an app... that automatically closes it.
About the GPS, the accuracy is greatly improved indeed. It takes me 1-3secs max to get a lock (with wireless networks disabled) and the accuracy is always 5meters.
Edit: There is a new Digital Clock service running now... I have no idea what makes it start, please let me know. I use Beautiful Widgets on my home screen.

The digital clock service should be part of the digital clock widget. You can try to end the process under running services and see if it stops it.

I downloaded the XXKH3 firmware but I'm not sure which files I should be using with Odin (Bootloader, PDA, Phone & CSC).

KayvinM said:
The digital clock service should be part of the digital clock widget. You can try to end the process under running services and see if it stops it.
Click to expand...
Click to collapse
I use Beautiful Widgets, so DigitalClock.apk should not be starting... Weird.
I just uninstalled the system app, no more running services. It was wasting my battery for nothing.
thvpham said:
I downloaded the XXKH3 firmware but I'm not sure which files I should be using with Odin (Bootloader, PDA, Phone & CSC).
Click to expand...
Click to collapse
See step 3 and skip the PIT file (re-partition unchecked). Also see the Update note into OP.

thvpham said:
I downloaded the XXKH3 firmware but I'm not sure which files I should be using with Odin (Bootloader, PDA, Phone & CSC).
Click to expand...
Click to collapse
I ended up re-downloading the XXKH3 from Intratech's thread and it was much easier flashing the one PDA file.
Now do I need to flash the XXKH3 stock kernel or my default stock Bell kernel?

You need the XXKH3 stock kernel, Intratech has it linked below the actual firmware link.

does it matter if CSC changes?
right now, (before root + update firmware), I still have BMC....
but once it's changed, would that create problems? If yes, what kind of problems. If no, then why do we care about CSC?

Personally, I used the samfirmware files and the phone works great. The pda.bell.ca info is present into ASN also.

Thanks for the responses everyone.
I ended flashing the stock XXKH3 kernel with the firmware. So far the upgrade has been good to me, I noticed improved battery life for the first 18 hours of usage. I will continue to use this build until I find something that is more stable and efficient then this.

A BIG THANK YOU!!!! I finally rooted and unlocked.
Originally: UGKF6
Now: XXKG5
Thanks for the guide!!!
Just 1 question though, do I HAVE TO do a factory after root? Any problem if I don't?

One thing is sure, the battery life degraded compared to XXKG3 firmware.
XXKG3 | XXKH3 (about 4hrs lost)
When I took the screenshot on KG3, I was using the phone for about 2 hours to read a book (notice the sudden drops because of the white screen), while the KH3 was always in sleep mode. So ya, there is a significant change in battery life with a tradeoff for the GPS gains.
I updated the OP.
clb09 said:
A BIG THANK YOU!!!! I finally rooted and unlocked.
Originally: UGKF6
Now: XXKG5
Thanks for the guide!!!
Just 1 question though, do I HAVE TO do a factory after root? Any problem if I don't?
Click to expand...
Click to collapse
Just curious, why you did not used the KH3 to take advantage of amazing GPS? The battery life should be a bit better also, compared to KG5. What do you mean by "do a factory"? You will lose root only if you flash back the firmware, flashing the kernel will not delete the su binary. You want to keep your phone rooted.
I strongly recommend you to spend $1 and get ChainsDD's Superuser Elite key, it will allow you to pin protect your rooted device. I upgraded to 3.0 Beta4 and everything works properly. Worth the dollar in so many ways, not just for securing the su access.

What you use to remove system app.
Thanks

Fizwiz said:
What you use to remove system app.
Thanks
Click to expand...
Click to collapse
I use Titanium Backup PRO. It allows me to backup, freeze and uninstall the unwanted apps.

One thing i have see with the XXKH3. With the KG2 im stable on H+, now im switching between 3G and H+.
Anyone else?

See Fast Dormancy info in OP. Is normal and the intended way to save you battery and bandwidth congestion.

Nook Simple Touch -> Nook Multi Touch [Screensaver Locking Issue Explanation Added]

Nook Simple Touch -> Nook Multi Touch [Screensaver Locking Issue Explanation Added]
After long discussion on how to enable multitouch
http://forum.xda-developers.com/showthread.php?t=1361296
Finally we get something very exciting,
mixing with the noRefresh app, thank to everyone developing this app
http://forum.xda-developers.com/showthread.php?t=1502723
==Exciting Videos==
AngryBird: http://www.youtube.com/watch?v=Chy0MGorjmo
Excellent PDF Reading: http://www.youtube.com/watch?v=JDk8a0leP4U
======For User======
For those who want a simple installation package
Can use the following update-package made by mali100, thanks to mali100
mali100 made an update-zip to install multitouch through CWM
[NST][CWR][RC2] Clockworkmod based Recovery
For thise users want to install manually
Can achieve Multi-touch by 2 Steps:
| Replacing Kernel:
| -make sure you haven't changed it before, otherwise u have to combine the changes and compile a new one
| -remember, a backup is a MUST
| for firmware 1.1 users
| Use Noogie or other methods, change the uImage with the attached one ( or the combined kernel mentioned below )
| arkusuma teaches us how to change uImage using ADB here
| *Thanks to arkusuma!
|
| Adding Permission node:
| in "/etc/permissions/required_hardware.xml", add
|
Code:
<feature name="android.hardware.touchscreen" />
<feature name="android.hardware.touchscreen.multitouch" />
|
| Reboot
For those users who also want to achieve USB host
Can find the combined kernel here: ( Thanks mali100! )
http://forum.xda-developers.com/showthread.php?p=24180134
Known Issue:
Sometimes the nook would act like un-responsive when it is in screensaver.
To solve it, try to drag the screen with two fingers.
The reason for this is, a cache is added between hardware input and linux subsystem, if the driver missed one of the "finger up" event before, it would result it leaving a phantom finger touching in your next touch. The screen cannot unlock by 2 fingers. But when you drag the screen with 2 fingers. It will clear all the cache, so as to erase the phantom touching.
Click to expand...
Click to collapse
======For Developer======
It is done by editing the kernel + adding permission node
*Thanks to arkusuma, who improved the code, added a cache for touching data, which prevents the pervious "un-stable" situation from happening
Kernel: just replace zforce.c, then compile
Two main changes on zforce,
first one is process_touch_event ( report touch information ),
second one is zforce_probe, this one just added a few input_set_abs_params ( register for device capability )
http://github.com/arkusuma/nook-touch-multitouch
Permission node: in "/etc/permissions/required_hardware.xml", add
Code:
<feature name="android.hardware.touchscreen" />
<feature name="android.hardware.touchscreen.multitouch" />
Click to expand...
Click to collapse
Thanks to arkusuma for improving the code again !

Why not work multi touch zoom in Opera mini?

love it ;]
also.. it works in OPERA 'mobile'.

osowiecki said:
love it ;]
also.. it works in OPERA 'mobile'.
Click to expand...
Click to collapse
Yes, you're right. Thank you.
PS: in UC Browser works too

Congrats on getting multitouch working!

wheilitjohnny,
Congrats on your feat! Maybe you should do a tutorial on how to install those files, for those poor lame souls like myself who can do simple things like run installer and such, even run a rooter, but need help on anything else.

Thank you for your support, I also wish to make a 1-click-install later.
But since the multi-touch is still not very smooth when the fingers are not moving, I want to package the things when I have a better release!
Wish that day comes earlier ^ ^

Could anyone say if kernel for 1.1 will work on 1.1.2? Then could someone compile one if it does not?

Hi, I've made some adjustment of wheilitjohnny's source. It seems to be working properly now, even when there's no finger movement. Changes can be viewed at github:
github.com/arkusuma/nook-touch-multitouch
I'm attaching the resulting uImage for those interested.

Cool ! Thanks arkusuma
You added a cache !
Seems that it is perfect now...
I wanna also improve the noRefresh app, make it being enabled when we are dragging......
But seems difficult

Now we get into the dueling uImages.
I guess that everybody will have to start building their own.
The problem is when somebody offers their uImage for Option A and somebody offers their uImage for Option B.
I could use a uImage for multitouch and USB host mode.
wheilitjohnny said:
I wanna also improve the noRefresh app, make it enable when we are dragging...
Click to expand...
Click to collapse
It's not difficult, but it has to (well, no, but most easily can be) integrated into the app.
I've got one of my personal apps that does this already.
I've stripped it down to a demo.
This only pans. Notice that it switches back and forth between A2 and normal modes.

Do the USB host one released the source code?
If yes, u can combine them and compile a whole new one to enjoy both hacks !
=======================
I just wonder, if it is possible, to make an app.
Getting information from the kernel directly, and set the mode using the raw information.
Then it can support all Apps
Any method for an app to read /dev/input/event2 ?

wheilitjohnny said:
Do the USB host one released the source code?
Click to expand...
Click to collapse
Yes, verygreen put it somewhere.
wheilitjohnny said:
Any method for an app to read /dev/input/event2 ?
Click to expand...
Click to collapse
Yes, /dev/input is where the good stuff is, but it's a bit more complicated.
The order of devices changes depending on what is connected/active.
Moreover, you can't really take over something that another process is reading.
Here's what my system is showing (with two USB keyboards plugged in ):
Code:
# ls -l /dev/input
crw-rw---- root input 13, 70 2012-03-27 08:34 event6
crw-rw---- root input 13, 33 2012-03-27 08:34 mouse1
crw-rw---- root input 13, 69 2012-03-27 08:34 event5
crw-rw---- root input 13, 68 2012-03-27 08:34 event4
crw-rw---- root input 13, 67 2012-03-27 08:34 event3
crw-rw---- root input 13, 66 2012-03-26 12:19 event2
crw-rw---- root input 13, 32 2012-03-26 12:19 mouse0
crw-rw---- root input 13, 63 2012-03-26 12:19 mice
crw-rw---- root input 13, 65 2012-03-26 12:19 event1
crw-rw---- root input 13, 64 2012-03-26 12:19 event0

maybe it is possible for me to add in dummy information in driver to raise extra input events.
my problem now is how an app (service in background) read device input event directly
I think we can make an input event separately from anything else
only let that app to read it, is it possible?
any permission stuff?
how to impletment the code in Java environment for the app?
how exactly the code should be typed?

Hi,
is this hack compatible with Edit n/reading now/side btns/RecentApps+ActivityPicker+ForceOrient from XorZone

tebra said:
Hi,
is this hack compatible with Edit n/reading now/side btns/RecentApps+ActivityPicker+ForceOrient from XorZone
Click to expand...
Click to collapse
Yes, this one is kernel based, XorZones is a hack of the framework.

I tried making "Dragging NoRefresh" using JNI
But the permission problem when I try to access /dev/input/event making me feel mad...

Really great news. i tried it with opera mobile, really good experience..
may i ask which pdf reader is this thats seen on the video?

Thanks for this!
Does anybody know how to flash a kernel image without using Noogie (using CWM, for example)?

drmxmyt said:
Really great news. i tried it with opera mobile, really good experience..
may i ask which pdf reader is this thats seen on the video?
Click to expand...
Click to collapse
that is ezPDF Reader
marspeople said:
Thanks for this!
Does anybody know how to flash a kernel image without using Noogie (using CWM, for example)?
Click to expand...
Click to collapse
is it possible to make it a "update-package" ? just like that one for official firmware update.

[FIX] Touchscreen freeze / dead zone(s) after MHC19J

..........
TLDR - Permanent Fix is in the 2nd post
..........
Update: [2016.11.28]
I created a NEW permanent fix that will work on all versions, MM 6.0.1, N 7.0, N 7.1.1. Does NOT require root/supersu, does NOT require running beta 7.1.1.
See 2nd post
Thanks to user Trevonn for uploading npf26f touchscreen firmware.
Click to expand...
Click to collapse
Update: [2016.11.23]
http://forum.xda-developers.com/nex...dead-zones-t3361123/post69748579#post69748579
https://code.google.com/p/android/issues/detail?id=205223#c146
According to user Trevonn and users on the google bug report thread, the previously mentioned fix appears to have made it into the beta release channel, Android 7.1.1 DP2
Click to expand...
Click to collapse
Update: [2016.10.14]
https://code.google.com/p/android/issues/detail?id=205223#c120
Project Member #120 [email protected]
Hi,
The development team has fixed the issue that you have reported and it will be available in a future build
Thanks
Status: FutureRelease
Click to expand...
Click to collapse
Update: [2016.10.12]
https://code.google.com/p/android/issues/detail?id=205223#c119
Project Member #119 [email protected]
Update : we are working on the fix and will update more on this when we will fix this issue
Click to expand...
Click to collapse
Update: [2016.10.05]
https://code.google.com/p/android/issues/detail?id=205223#c112
Project Member #112 [email protected]
We are still working on the issue, we will update on this once we have any updates
Click to expand...
Click to collapse
Update: [2016.09.26]
Google finally looking into the problem and changed priority from small to high.
https://code.google.com/p/android/issues/detail?id=205223#c96
Project Member #96 [email protected]
update: This issue was tough to reproduce, we have got all the information from the external thread and we are making progress on it, thanks for the inputs. we will keep you posted more on this issue as it becomes available
Cc: [email protected]
Labels: -Priority-Small Priority-High
Click to expand...
Click to collapse
Update: [2016.09.03]
Due to security changes in Android N (Nougat) 7.0 you now need to have SuperSU installed for this fix to work.
Android M (Marshmallow) 6.x.x users do not need to have SuperSU installed, though it would be preferable.
Update: [2016.07.23]
Video demonstration of issue (thanks Troy Spicer):
https://www.youtube.com/watch?v=sfoAVnFFZrg
Update: [2016.06.21]
Google finally assigned the bug to development for further investigation.
If someone at Google is reading this thread, the super quick way to mitigate the problem is to simply package the older synaptics touchscreen firmware released with mmb29k-mmb29v and update the version # so it will overwrite existing firmware.
You can figure out what is wrong with the touchscreen firmware at a later date.
The downside of rolling back, ie having a touchscreen that doesn't behave ONLY while charging for some people where the end-user can obtain a new charger and workaround the problem, if they even use the phone while charging, is IMO better than having a touchscreen that is unusable for some people ALL the time with no simple workaround for the average user other than RMA.
https://code.google.com/p/android/issues/detail?id=205223#c54
Project Member #54 [email protected]
Hi,
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks
Status: Assigned
Labels: Defect-29526586
Click to expand...
Click to collapse
Background:
There is a well documented problem for some charger/device/voltage combos where the touchscreen will become unresponsive when connected to the stock charger. Ultimately the problem is with the charger design but it appears Google made some attempt to mitigate the problem with software in the MHC19J release.
See this thread for the power adapter touchscreen not responsive details
https://productforums.google.com/forum/#!msg/nexus/-rSxrBUMKr0/ao-N4Y6nAgAJ
Unfortunately in doing so it seems they may have put out a Synaptics touchscreen firmware that introduced a brand new problem for folks who've never had any touchscreen problems before, affecting them during *normal* usage rather than the more isolated case of only during charging.
Basically the symptoms are you start getting freezes / dead zones when you leave your device untouched for a couple of seconds. You can cycle the screen on/off to reset the touchscreen but the problem eventually comes back again after a few seconds. It even occurs upon startup when you need to enter your lock code or pattern, making it difficult to get into your device. For most people it will be on the right side of the screen and happen after about 6 seconds of inactivity. Swiping from left to right will sometimes restore responsiveness for a few more seconds.
My theory is Google put out a new Synaptics touchscreen firmware that adjusted the sensitivity of the touchscreen to compensate for the "noise" being generated by the bad power adapters. The change may have been too aggressive as it seems to have had a side effect of being too insensitive for some folks' touchscreen variations resulting in freezes / dead zones.
See these threads for the touchscreen freezes / dead zones after MHC19J details
http://forum.xda-developers.com/nexus-5x/help/touchscreen-freeze-t3335521
https://code.google.com/p/android/issues/detail?id=205223
https://www.reddit.com/r/nexus5x/comments/4anxs3/nexus_5x_not_responding_to_touches_occasionally/
So normally you'd just flash an older factory image and everything would be back to normal. Unfortunately for touchscreen firmware, flashing older factory images will have no effect. Once you have the new touchscreen firmware it will stay in place until a newer one comes out. Thus you can't actually get back to "true" factory by flashing the MDA89E factory image.
There is a way you can force a touchscreen firmware flash. This will be described in the next post.

NEW permanent fix (thanks trevonn for uploading the npf26f firmware)
As of 11/22/16 Google has finally released a fix for the touchscreen, but only on the beta channel.
Either install Android 7.1.1 DP2 NPF26F (or newer)
or
run the following update-touch-npf26f.zip in TWRP.
DOES require unlocked bootloader
does NOT require you to run beta 7.1.1
does NOT require root/supersu
makes NO modifications to your system nor vendor partitions
you will still be completely stock once the update is done, touchscreen firmware is uploaded to the screen's internal processor
IS persistent, you can install any ROM, custom, stock, doesn't matter, fix will remain​=======================
OLD instructions
To make it easier for people to try this fix, I created an update.zip that can be run from TWRP. This will roll back your Synaptics touchscreen firmware to the one that was included with MMB29K - MMB29V and thus fix the problem described above.
The old manual method is still available in the post below.
Update: On Android N (Nougat) 7.0 in addition to bootloader being unlocked you MUST install SuperSU 2.77 or newer PRIOR to running update-touch-vendor.zip There was a security change in 7.0 that causes data written to /vendor to rollback to original. Changes are physically there but get treated as data corruption and "fixed" automaticaly by reed solomon forward error correction. This auto-correct "feature" is disabled if dm-verity is disabled (installing SuperSU would take care of this for you)
You DO need to unlock your bootloader but you do NOT need to be root, however if you choose the 2nd option (update-touch-vendor) it would be best if you were root or you'll see the RED Android corrupt message.
The reason that happens with the 2nd option (update-touch-vendor) is to allow you to run the older touchscreen firmware with a ROM MHC19J (or newer) the /vendor partition needs to be modified to include the older touchscreen firmware (otherwise upon first boot, your rolled back touch screen firmware will get overwritten with the newer touchscreen firmware in /vendor/firmware). Because of how the Merkel-hashtree verification works, if you touch anything in /vendor (or /system), even just changing the date on a file or mounting r/w, it will complain about corruption. If you are running root, it will disable the dm-verity checks for /vendor (and /system), and you will just see the standard ORANGE bootloader unlocked warning.
This was ONLY tested with TWRP 3.0.2-0 for Marshmallow and TWRP 3.0.2-2 for Nougat and with stock ROMs, though it should work with most if not all ROMs.
I ONLY tested it with TWRP flashed onto the recovery partition (ie did not test temporarily loading twrp using "fastboot boot twrp.img")
There are two files available:
update-touch.zip - install this file using TWRP if you just want to rollback the touchscreen firmware.
This REQUIRES you first flash a release OLDER than MHC19J, for example MMB29V and
Do NOT upgrade to MHC19J (or newer) until Google fixes the problem
update-touch-vendor.zip - install this file using TWRP if you would like to rollback your touchscreen firmware
AND keep your existing MHC19J (or newer) Android system release
I also suggest you DISABLE your lockscreen PIN/Pattern before doing any installing of update-touch-vendor.
It is generally good practice to do this whenever you start modifying partitions that are being verified, otherwise parts of Android can get confused and think your phone is stolen and someone is trying to break in, thus attempt to lock you out.

This is the sysfs path for the touchscreen interface
/sys/bus/i2c/drivers/synaptics_rmi4_i2c/2-0020
Code:
[email protected]:/sys/bus/i2c/drivers/synaptics_rmi4_i2c/2-0020 # ls -l
-rw-rw-r-- root root 4096 2016-04-18 00:30 0dbutton
-r--r--r-- root root 4096 2016-04-18 00:30 blconfigblockcount
-r--r--r-- root root 4096 2016-04-18 00:30 blocksize
-r--r--r-- root root 4096 2016-04-18 00:30 buildid
--w--w---- root root 4096 2016-04-18 00:30 check_fw
-r--r--r-- root root 4096 2016-04-18 00:30 config_id
--w--w---- root root 4096 2016-04-18 00:30 configarea
-r--r--r-- root root 4096 2016-04-18 00:30 configblockcount
-rw-rw-r-- root root 0 2016-04-18 00:30 data
-r--r--r-- root root 4096 2016-04-18 00:30 dispconfigblockcount
lrwxrwxrwx root root 2016-04-18 00:30 driver -> ../../../../../bus/i2c/drivers/synaptics_rmi4_i2c
-r--r--r-- root root 4096 2016-04-18 00:30 flashprog
-rw-rw-r-- root root 4096 2016-04-18 00:30 flipx
-rw-rw-r-- root root 4096 2016-04-18 00:30 flipy
--w--w---- root root 4096 2016-04-18 00:30 force_update_fw
-rw-rw-r-- root root 4096 2016-04-18 00:30 full_pm_cycle
-rw-rw-r-- root root 4096 2016-04-18 00:30 fw_name
-r--r--r-- root root 4096 2016-04-18 00:30 fwblockcount
--w--w---- root root 4096 2016-04-18 00:30 imagesize
drwxr-xr-x root root 2016-04-18 00:30 input
-r--r--r-- root root 4096 2016-04-18 00:30 modalias
-r--r--r-- root root 4096 2016-04-18 00:30 name
-r--r--r-- root root 4096 2016-04-18 00:30 package_id
-r--r--r-- root root 4096 2016-04-18 00:30 permconfigblockcount
drwxr-xr-x root root 2016-04-18 00:30 power
-r--r--r-- root root 4096 2016-04-18 00:30 productinfo
--w--w---- root root 4096 2016-04-18 00:30 readconfig
-rw-r--r-- root root 4096 2016-04-18 00:30 reg_control
--w--w---- root root 4096 2016-04-18 00:30 reset
lrwxrwxrwx root root 2016-04-18 00:30 subsystem -> ../../../../../bus/i2c
-rw-r--r-- root root 4096 2016-04-18 00:30 uevent
--w--w---- root root 4096 2016-04-18 00:30 update_fw
--w--w---- root root 4096 2016-04-18 00:30 writeconfig
--w--w---- root root 4096 2016-04-18 00:30 writelockdown
Between using "update_fw" and "force_update_fw" you can force a firmware rollback.
So if someone who is affected by this bug would like to try and fix it, flash the factory image
for something EARLIER than MHC19J, let's say MMB29V.
Caveats
whenever you flash firmware you can seriously damage your device
this is slightly more dangerous than ROM flashes because if something goes wrong
your touchscreen might stop working, making it hard to interact with your device
firmware can NOT update when your screen is off / device is sleeping
make sure your device isn't suspended/sleeping, ie you can see your home screen
disable or lengthen your screen timeout so the touchscreen doesn't get turned off during the flash process
the "force_update_fw" command WILL take a 1 or 2 minutes
Do NOT interrupt the process or you can have a non-functioning touchscreen
Then you can try in an "adb shell" [need to be rooted]
Code:
su
cd /sys/bus/i2c/drivers/synaptics_rmi4_i2c/2-0020
cat buildid
echo 1 > force_update_fw
cat buildid
dmesg | grep rmi4_i2c > /sdcard/fwlog.txt
Theoretically your buildid before and after the flash should be different. If you check the log file
you can be sure whether the touchscreen firmware was written or not.
Restart your device and see if the touchscreen is back to normal.
If it is back to normal, then be happy and do NOT take any updates MHC19J or newer or you
will get the questionable touchscreen firmware again.
I've attached the mmb29k-mmb29v synaptics_fw.bin [MD5: a35f302acf40e28b4330ce9912c9bf0a]
If you want to use the latest ROM release and don't mind being rooted
FIX your touchscreen as described above
disable any lockscreen/pattern/PIN
manually flash the latest factory image (wiping user partition not necessary, but won't hurt)
*PRIOR* to rebooting, flash TWRP recovery
boot to TWRP recovery
the following steps WILL modify your vendor partition, as long as you are rooted you won't really
see any difference, but if you put stock boot.img back, it will complain about corrupted software
mount /vendor partition r/w
replace /vendor/firmware/synaptics_fw.bin with the attached one
unmount /vendor
flash SuperSU
reboot
reenable lockscreen/pattern/PIN
it is important to do this *PRIOR* to first system/rom boot after flashing the new factory image
or you will be stuck with the new (bad) touchscreen firmware again

In case anyone is curious there have been 3 touchscreen firmware updates since original release. These cannot be rolled back using factory images. Once you install these Android releases, for better or for worse, you get the associated touchscreen firmware.
So for example, once you get the mhc19j (or newer) update, you are stuck with the mhc19j touchscreen firmware even if you flash mda89e factory images to try and get back to stock. Factory Reset will NOT roll back the touchscreen firmware either.
This is the likely reason some people on this thread are experiencing very annoying touchscreen behavior seemingly appearing overnight when your phones picked up the mhc19j update. I am guessing they adjusted the touchscreen firmware to try and compensate for the "noise" from the defective chargers and were too aggressive, ending up causing issues for people who aren't even plugged in and have never had touchscreen issues.
mhc19q did not include any new touchscreen firmware so upgrading to that will have no effect.
If I didn't list a release it just means it is using the same firmware as the most recent listed predecessor.
mda89e
original synaptics touchscreen
mdb08i
updated synaptics touchscreen
updated qualcomm wireless lan
updated DRM
mmb29k
updated synaptics touchscreen
updated fingerprint
updated sensors
updated qualcomm wireless lan
updated qualcomm video
updated modem
mhc19j
updated synaptics touchscreen
updated sensors
updated bluetooth
updated modem
updated DRM
mtc20k
synaptics touchscreen firmware unchanged since mhc19j
other firmware unchanged since mhc19j
nrd90m (as compared to mtc20f)
synaptics touchscreen firmware unchanged since mhc19j
updated adreno
updated qualcomm wireless lan
updated bluetooth
updated fingerprint
updated DRM
n5d91l
synaptics touchscreen firmware unchanged since mhc19j
other firmware unchanged since nrd90m

Ok, this is now confirmed to FIX the issue.
No longer necessary to throw your 5x against the wall, curse Google, and/or schedule an RMA.
http://forum.xda-developers.com/showpost.php?p=66436391&postcount=28
unicorns-fart-rainbows said:
I downloaded the MMB29V image and followed sfhub's instructions to reflash the synaptics_rmi4_i2c firmware . Happy to report that the issue is fixed, screen works well .
Also, I'm not sure if it was mentioned elsewhere in this thread. The unresponsive screen primarily effects the right side. It occurs after 6 seconds of screen inactivity. It took me a while to figure out that swiping from the left to the to the right side restored screen responsiveness. Still super annoying, but way less frustrating than randomly clicking around until it magically works again, or spamming the power button.
Click to expand...
Click to collapse

My Touchscreen is kinda unresponsive compared to my Nexus 6p or Nexus 5.
I flashed the newest factory image right after I received it a few days ago and I'm wondering if the low sensivity could be caused by the touchscreen firmware.

If it is low sensitivy during chagring, that is the fault of the charger generating too much noise.
If it is low sensiting during normal usage, possibly it is the touchscreen firmware, but folks on that have been hit by this problem have very specific symptoms. The right side of their screen becomes unresponsive after around 6 seconds of inactivity. They can get it to respond again by swiping left to right or by cycling the screen using the power button.

My Touchscreen is unresponsive all the time, not just on a specific side or something.

This might help or might not. Your symptoms don't match but there are always variances in the manufacturing of touchscreens. I'd say it is worth a try.
Do you have a screen protector? Sometimes those can change the figures enough to confuse the touchscreen. I noticed my friend was using my phone and it was very hard to tap then I tried it and all the taps went through. That person told me they have problems on lots of phones and can't use screen protectors which I assume means the conductivity of their fingers is different than most people.
Also does it make a difference when the device is plugged in. I don't mean is it necessarily better when plugged in, just is it different, worse or better.

I used a glass protector and had to remove it cause it even lowered the sensivity even more.
So I'm without a protector at the moment.

I am PIE user and this touchscreen problem was making me mad. I just used update-touch-vendor.zip and everything is fine again! Thanks!
Install script said in TWRP "md5 check for dest touchscreen firmware failed" but before that I could not see errors and problem is solved so it seems to work.

makux said:
I am PIE user and this touchscreen problem was making me mad. I just used update-touch-vendor.zip and everything is fine again! Thanks!
Install script said in TWRP "md5 check for dest touchscreen firmware failed" but before that I could not see errors and problem is solved so it seems to work.
Click to expand...
Click to collapse
Glad it fixed your problem.
The install script you used will flash the firmware first, then it will copy the same firmware just flashed into the vendor firmware directory so the "bad" firmware doesn't get reloaded.
It checks the md5 checksum before flashing (and aborts if there is a problem) so your flash went fine (as evidence by your problem being fixed)
When the install goes to copy the firmware to vendor, it also checks the checksum after it copies to /vendor/firmware/synaptics_fw.bin (when the script is running it is slightly different mount point, but that is the directory when your system is booted)
That is the error you are seeing. It could be some permission problem or could be a bad copy. Not sure.
If you want to do some testing in a rooted adb shell
su
cd /vendor/firmware
ls -l synaptics_fw.*
md5sum synaptics_fw.*
You should see a listing for synaptics_fw.bin and synaptics_fw.bak The latter is the backup of your old firmware (prior to copy) in your /vendor/firmware partition.
File size for synaptics_fw.bin should be 96,000
md5sum for synaptics_fw.bin should be f7fbe71fd16807fc4b198e21ea4be6ff
If it isn't post the size and md5sum and I will try and figure out what firmware you have or if the copying got corrupted.
BTW by PIE user are you using some extended desktop where the Android controls slide out when needed? I can see one edge of the screen not being responsive being very annoying for that feature. It is possible the partition / mounts are slightly different for custom ROMs and/or different versions of TWRP (and that could be causing some problem with the copying). I only tested the install script on stock systems running TWRP 3.0.2-0.

TWRP version is the same.
But that not stock ROM or something might be the case.
I use Tesla rom 20160423-2024 + PIE from xposed/gravitybox (left and right side only) and problem was only at the right side. I have also disabled navbar.
After flashing zip I have have had zero problems.
And this is what I see now (no bak file) :
[email protected]:/vendor/firmware # ls -l syna*
-rw-rw-rw- root root 96000 2016-04-29 09:06 synaptics_fw.bin
[email protected]:/vendor/firmware # md5sum syna*
f7fbe71fd16807fc4b198e21ea4be6ff synaptics_fw.bin
[email protected]:/vendor/firmware #
But I also tested writing this with original charger and writing was almost impossible to do because of slowliness and touch problems. I removed the cable and all is ok again.
So definitely firmware is now changed, I do not remember that charger problem has happened before.
Anyway, this way is much better.

makux said:
[email protected]:/vendor/firmware # ls -l syna*
-rw-rw-rw- root root 96000 2016-04-29 09:06 synaptics_fw.bin
[email protected]:/vendor/firmware # md5sum syna*
f7fbe71fd16807fc4b198e21ea4be6ff synaptics_fw.bin
[email protected]:/vendor/firmware #
Click to expand...
Click to collapse
I had a mistake in the file size listed in the previous post, which I corrected. You have the correct file, the correct file size, and the correct md5 in your /vendor/firmware directory. I am not sure why the install script complained about md5 check earlier.
makux said:
But I also tested writing this with original charger and writing was almost impossible to do because of slowliness and touch problems. I removed the cable and all is ok again.
So definitely firmware is now changed, I do not remember that charger problem has happened before.
Click to expand...
Click to collapse
The touch problems with charger is because the early manufacture dates came with a defective charger which produced too much noise. They fixed the problem in newer chargers and they also tried to address the problem by adjusting touchscreen firmware sensitivity. However for *some* touchscreens, the "fix" led to the unresponsive right side of screen.
So previously you would have had probably less touch problems with charger connected, but right side of screen unresponsive after 6 seconds. The older touchscreen firmware (which you just flashed) would give you normal touchscreen, but you would be exposed to full effects of defective noisy charger when charging cable connected.
Since the latter case is much more usable, my suggestion is to use a different charger or get your charger replaced with the fixed one.

Just a question, please: where are the new touchscreen and other components firmware included? Are they inside vendor.img? Thanks!

gpvecchi said:
Just a question, please: where are the new touchscreen and other components firmware included? Are they inside vendor.img? Thanks!
Click to expand...
Click to collapse
the touchscreen firmware is initially located in vendor.img mounted at /vendor but after first boot the touchscreen firmware (if newer than existing) is uploaded into touchscreen private area so even if you replaced vendor.img it won't make a difference unless vendor.img includes newer touchscreen firnware. The private version of touchscreen firnware is what is run, not the one in vendor.img (at least not directly)

hi brother thank you for the great effort recently the device get an update MTC19T
i feel better touch screen response although it is not perfect but it's definitely better
so can you check if we have new touch screen update in this package.
and i feel charging is a little bit slower
r u recommending flash the old vendor or stay in the latest version?

MORADESSA said:
hi brother thank you for the great effort recently the device get an update MTC19T
i feel better touch screen response although it is not perfect but it's definitely better
so can you check if we have new touch screen update in this package.
and i feel charging is a little bit slower
r u recommending flash the old vendor or stay in the latest version?
Click to expand...
Click to collapse
I was traveling so only got a chance to take a quick look but I recall the touchscreen firmware did not change in the latest MTC19T release so it should be the same as the one in MHC19J (and MHC19Q)
If your touchscreen has always been flaky then it might not have to do with the firmware. If it was fine the whole time and suddenly started acting funny after MHC19J/MHC19Q/MTC19T then it is worth your time to try older touchscreen firmware.
Otherwise, you could try, but the chances of resolving your issues are lower.

MORADESSA said:
hi brother thank you for the great effort recently the device get an update MTC19T
i feel better touch screen response although it is not perfect but it's definitely better
so can you check if we have new touch screen update in this package.
Click to expand...
Click to collapse
Sorry I didn't get back to you sooner, but I did confirm what I mentioned in the previous message.
MTC19T synaptics touchscreen firmware has the same MD5 hash as MHC19J (and MHC19Q) so the firmware files are exactly the same.

sfhub said:
Sorry I didn't get back to you sooner, but I did confirm what I mentioned in the previous message.
MTC19T synaptics touchscreen firmware has the same MD5 hash as MHC19J (and MHC19Q) so the firmware files are exactly the same.
Click to expand...
Click to collapse
MTC19V synaptics touchscreen firmware also has the same MD5 hash as MHC19J (and MHC19Q) so if you have this touchscreen issue the newer software release likely won't fix it.