เปิดไฟล์ contact.cvf ไม่ให้เป็นภาษาต่างด้าว

ในการเปิดไฟล์ contact.cvf  ไม่ให้เป็นภาษาต่างด้าว เมื่อรายชื่อเราเป็นภาษาไทย เราอาจทำได้ 3 วิธี
ภาพล่าง คือตัวอย่าง เปิด cvf ไฟล์กับ excel  (FN คือ firstname ชื่อ ที่เป็นภาษาต่างด้าว)

1.ใช้ editplus เปิด ตัวโปรแกรมน่าจะ detect  encode page ของไฟล์ได้

2.เอาเข้า contact app ของ google
-***contact google สามารถรวมชื่อซ้ำกันได้ และส่งออกไฟล์ เป็น html ได้ เพื่อเก็บไว้ดูที่หลัง

-นำเข้า ไฟล์ cvf

***ภาพด้านล่างคือไฟล์ html ที่ส่งออกจาก contact google

***contact google จะได้รูปแบบรายชื่อที่ดูง่าย เมื่อสั่งวิวและพิมพ์โดยเลือกรายชื่อที่ต้องการจะพิมพ์ได้จากทั้งหมดที่มีอยู่

3.ใช้ excel นำเข้า cvf ไฟล์ เลือก format เป็น unicode UTF-8
  เราลองสลับรายการ การเข้ารหัสภาษา โดยเลือก ช่อง  file origin  ว่า cvf ไฟล์ใช้ วิธีไหนอ่านภาษาได้ถูกต้อง

adb command 4 Disable the lock screen getevent sendevent

https://www.reddit.com/r/Android/comments/1r2zha/how_i_managed_to_use_my_android_device_with_a
adb shell su am start -a android.bluetooth.adapter.action.REQUEST_ENABLE

sqlite3 settings.db update global set value=1 where name='bluetooth_on';

"am start -a android.intent.action.MAIN -n com.android.browser/.BrowserActivity"

adb shell getevent

Or to record a specific device:

adb shell getevent /dev/input/eventx

Then simuate recorded input with:

adb shell sendevent /dev/input/eventx

Disable the lock screen through USB debugging. Must manually edit one of Android's sqlite3 databases to do this. (Do not copy/paste in bulk. It won't work due to changing shells and programs.)

adb shell
su
cp /data/data/com.android.providers.settings/databases/settings.db /sdcard/settings.db
chmod 665 /sdcard/settings.db
exit
exit
adb pull /sdcard/settings.db settings.db
sqlite3 settings.db
insert into secure (name, value) values ('lockscreen.password_type',65536);
update secure set value=1 where name='lockscreen.disabled';
^D
adb push settings.db /sdcard/settings.db
adb shell
su
cd /data/data/com.android.providers.settings/databases/
mv settings.db settings.db.bak
cp /sdcard/settings.db settings.db
chown system:system settings.db
chmod 660 settings.db
exit
exit
adb reboot

adb command4 call

adb shell am start -a android.intent.action.CALL -d tel:025555555


https://github.com/cesards/AndroidShell

Auto Backup Data (only in Android M)

$ adb shell bmgr

$ adb shell bmgr run
# do some work in the app
$ adb shell bmgr fullbackup com.domain.android.app_name
# uninstall and reinstall the app
$ adb shell bmgr restore com.domain.android.app_name

Simulate fingerprint inputs (only in Android M)

$ adb -e emu finger touch 1

adb backup ab to tar

http://forum.xda-developers.com/galaxy-nexus/general/guide-phone-backup-unlock-root-t1420351

Like a lot of you, I have been putting off unlocking the bootloader on my Nexus because I didn't want to have to go through the hassle of backing up everything manually and restoring individual application data; logging back into apps; saving settings; etc. I found an undocumented (at least as far as my googling was able to find) feature in the latest version of the ADB platform tools (for Android 4.0+) that allows you to create a full system backup, including app apks, their respective data, as well as the internal storage. 

Keep in mind this is experimental and not exactly publicized as a feature of ICS, so don't count on this as your only method of backup!

This guide assumes you have already installed the Android SDK, and updated the Android SDK Platform Tools to the latest version (currently Rev 10) using the SDK Manager.

1. Connect your device via USB, and open a command prompt.

2. Optionally, type the command 'adb devices' to ensure that your device is properly recognized. If you're comfortable with ADB already, just skip this.

There is a command, 'adb backup' (to be detailed shortly), that will now allow you to create a full system backup. 

The command parameters format is:

Quote:

adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all] [-system|nosystem] [<packages...>]

The most basic command you can use* is simply:

Quote:

adb backup -all

This will use the defaults to backup only app and device data (not the APKs themselves) to the current directory as 'backup.ab'

* This may not work for every setup. If you get an error such as "adb: cannot open file ./backup.ab", use:

Quote:

adb backup -all -f C:\backup.ab

Or substitute the path of your choice in place of C:\.

To explain the parameters:

Quote:

-f <file>

Use this to choose where the backup file will be stored, e.g. '-f /backup/mybackup.ab', which will save it at the root of your drive (C:\ for Windows, etc.) in a folder called backup, as a file named 'mybackup.ab'. I recommend using this flag to set a location manually, as with my first backup test, it said that it completed successfully, but I was unable to locate the backup file. I have no idea where it was saved, but it wasn't where it should have been located.

Quote:

-apk|-noapk

This flags whether or not the APKs should be included in the backup or just the apps' respective data. I personally use -apk just in case the app isn't available in the Market, so that I don't have to go hunt it down again. The default is -noapk.

Quote:

-shared|-noshared

This flag is used to "enable/disable backup of the device's shared storage / SD card contents; the default is noshared.", which for the Nexus I would certainly flag to -shared, but from my test, it did not restore all of the contents of my internal storage, so I recommend backing up music, pictures, video, and other internal storage items manually, just to be on the safe side. The default is -noshared.

Quote:

-all

This flag is just an easy way to say to backup ALL apps. The packages flag (further on) can be used to choose individual packages, but unless you're just wanting to backup a specific application, use -all for a full system backup.

Quote:

-system|-nosystem

This flag sets whether or not the -all flag also includes system applications or not. I used -system, but this is probably unnecessary, and I would almost guess that it is safer to use -nosystem, but use your own judgment on this. The default is -system.

Quote:

<packages...>

Here you can list the package names (e.g. com.google.android.apps.plus) specifically that you would like to backup. Use this only if you're looking to backup a specific application.

3. Once you've made your decision on how to perform the backup, simply type the command as you would like it; in my case, this is the command that I used:

Quote:

adb backup -apk -shared -all -f C:\backup20111230.ab

4. You will see a screen like the following:



5. Enter a password (if desired) for encryption of the backup file. RETAIN THIS PASSWORD FOR RESTORING LATER.

6. This process will take several minutes to complete, depending on the settings you've chosen, but when completed, you will get a toast on-screen saying 'Backup Complete', or if you miss that, you'll know once your phone returns to the home screen.

7. Now go unlock your bootloader (not going to go into the process for this guide, but you probably know how already, and if not, there are several guides a search away).

8. Once you're booted back into Android, you can choose to add your account now, or skip that for later. I skipped it for later, but I think it might make the process more smooth to sign in before the restore. YMMV. 

9. To restore, with your device connected open your command prompt again, and type:

Quote:

adb restore C:\backup20111230.ab

replacing 'C:\backup20111230.ab' with the location of your backup file. 

10. You will see a screen like the one below:



11. Simply type in your current encryption password (if you've set one), and the password with which the backup was encrypted (if you chose to set a password), and the restore will begin. It again will take several minutes depending on the size of the backup and the options chosen.

12. You're back to normal, short of possibly some widgets on the home screen. My wallpaper was even restored, my app folders remained just as I had them before, my alarms remained, and for most applications, I didn't even have to log back in; it kept everything. 

________________________

NOTE: I did have an issue with not all files being restored to the Internal Storage; in particular, the Gallery still displayed all the folders and files that it had cached (which it expected to be there) as only gray boxes, and would not display the images, nor would it rescan the media. I simply copied the files back to the Internal Storage directory manually, and all was well again. Again, YMMV. 

NOTE 12/31: Also to note, this will not back up SMS messages, so if you're concerned about those, you may want to look into an alternative application to back up SMS. 

NOTE 06/12: There seems to be a bug in which backup and restore operations will fail unless a desktop backup password is set under Developer Options. It will not work with a blank password.

Hope this is able to help! If so, give me a thanks () and let me know how your experience goes.

=====================


http://android.stackexchange.com/questions/28481/how-do-you-extract-an-apps-data-from-a-full-backup-made-through-adb-backup

Just for reference of others, here is some background on the .ab file format.

The Android Backup (*.ab) file is a compressed TAR file. It is compressed using the DEFLATEalgorithm. On top of that, there can be AES encryption used. This is determined when you create the backup, if you enter a password then the backup is encrypted, otherwise; there is no encryption, it is only compressed.

The HEADER of the file is a little different than a normal DEFLATE archive. It contains information about the backup and looks like the following:

ANDROID BACKUP
1
1
none

The first line is the "Magic" line. The next line is the version of the Android Backup file format. The next line is a boolean (true or false, 1 or 0) indicating if the file is compressed. The last line is the type of encryption. This example is not using any encryption. If there was a password, the line would read "AES-256". After that is the encryption cipher. If no password, then the DEFLATE "archive" starts.

It is compressed using the Java Deflater. Which, from a developers perspective, causes issues if you want to use anything besides Java to extract it. I haven't been able to find anything that can deflate it using the same algorithm, even though all that I have found (for like C#) are supposed to follow the "SPEC".

With that said, there is an open source project under the Apache 2.0 license, written by Nikolay Elenkov that will allow you to extract the .ab in to a tar file.

Usage:

java -jar abe.jar unpack <backup.ab> <backup.tar> <password>

If you are not sure how to really use that (which is beyond the scope of this answer) the next version of Droid Explorer v0.8.8.7 (available here) will allow you to do exactly this, and more, right from Explorer. You can read more about the features on my blog (yes, i know, shameless plug. I do that when it fits the question)

One more option is to use bash, cat and gunzip (gzip).

The full process could be this (with an unencrypted backup):

1. backup one app's data (for example "Override DNS for KitKat"):

   $ adb backup -f net.mx17.overridedns.ab -noapk net.mx17.overridedns
   Now unlock your device and confirm the backup operation.
   

2. extract the compressed data

   $ dd if=net.mx17.overridedns.ab bs=1 skip=24 > compressed-data
   1285+0 records in
   1285+0 records out
   1285 bytes (1,3 kB) copied, 0,00745877 s, 172 kB/s
   

3. decompress the compressed data

   $ printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" \
       | cat - compressed-data | gunzip -c > decompressed-data.tar
   gzip: stdin: unexpected end of file
   

4. "untar" the tar file

   $ tar xf decompressed-data.tar

prop adb remount,adb root and adb shell's prompt root ,adb root and adb push pull ,edit boot.img

4.For permanent adb root, you'll have to extract boot.img, change default.prop, repack and then flash it back to device

echo ro.secure=0 >/data/local.prop เซตค่าใน prop แต่ local.prop มีใน v4.0

==================
 ro.secure=0
init.rc default.prop,local.propand other environment variables.
If it finds build.prop,default.prop or local.prop property

adb remount,adb root and adb shell's prompt'll be # by default.

 setprop ro.mtk.hardware mt6589
=======
 Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"
=======
http://forum.xda-developers.com/showthread.php?t=2593581
Note: Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"

The Problem:
I am a heavy ADB user (QtADB) and was having problems getting it to mount /system rw and pushing/editing files in real time. Had no problems doing all this by mounting /system in recovery but rebooting the phone just to make some system files changes is kind of inconvenient. So I did some research and found this:

Quote:
Originally Posted by HEXcube
The real reason behind adb root or insecure adb is the adb daemon in the device running at root permissions. In pre-Android 4.1 versions, this is usually decided by some initialisation script(like init.rc) at boot time. The script checks for value in default.prop,local.propand other environment variables.
If it finds build.prop,default.prop or local.prop property file with ro.secure=0 adbd is allowed to run as root. You'll get adb root and hence will be able to do commands like adb remount,adb root and adb shell's prompt'll be # by default. The user may be displayed as root@root or root@shell. adb GUIs like Android Commander and QtADB will get to work in Root mode.
But,if it's ro.secure=1, adb daemon is made to work in secure mode, and adb won't change to root mode on issuing adb root command. However, if su binary is present in $PATH, u can still call su command from adb shell. But, it's not enough for Android Commander to get Root Access. It is possible to attain adb root through any one of the following methods:
1.For CyanoGenMod based ROMs there is an option in Settings->Developer Settings->Root access to control root access. Choose ADB only or Apps and ADB in options to get adb root.
2.Else use adbd Insecure app by chainfire if you have a rooted device. This is useful, especially for Android 4.1+ devices.
3.Or, you may manually edit default.prop to set it's value to 0, but original default.prop will be restored from boot partition everytime you reboot(this is the reason why adb Insecure cannot permanently do adb root, though there is an option to repeat the rooting procedure everytime the device boots). This method is called temporary adb root. On pre-Android 4.0 ROMs default.prop file was located in / directory. I read that from Android 4.x this file is in ramdisk and so more difficult to edit. But Android 4.0 has local.prop which is easier to modify than default.prop( See method 5)
4.For permanent adb root, you'll have to extract boot.img, change default.prop, repack and then flash it back to device.
5. In Android 4.0 there's local.prop file in /data partition. Setting ro.secure=0 in this file will do adb root permanently. Else you can set another property ro.kernel.qemu=1 in the same file. But, this value makes the system think that it is running in an android emulator. Many exploits and root methods set this property temporarily to gain root. But, it may cause side effects if used permanently. Setting ro.secure=0 is recommended. Do this command in terminal app or adb shell:
echo ro.secure=0 >/data/local.prop
or you can manually copy a local.prop file with ro.secure=0 as it's content to /data.
6.Note that method 3,4 and 5 won't work in Android 4.0 Jelly Bean onwards. According to Dan Rosenburg(drjbliss in XDA),the researcher who discovered adb root emulator exploit and many other exploits, Jelly Bean doesn't parse any property files to set the ownership of adb daemon. The stock adbd will have to be replaced with an insecure one to gain adb root. But still,as adbd is located in /sbin whose contents are reloaded everytime on reboot from boot.img, it won't be permanent.
7. For permanent adb root, you may flash an insecure boot.img(one that contains and insecure adbd)
8. If you're really desperate and can't get adb root to work with any of the above methods use an exploit. Most of the adb based rooting methods utilise some exploit to make the adb daemon run as root. By studying the exploit and implementing it you could gain adb root atleast temporarily.I'm not recommending this method but as a last resort you could try them.
Acknowledgements: Thanks to Dan Rosenberg for explaining the reasons behind adb root, especially the one in Jelly Bean.

Original thread: Can't get ADB Root Access in certain ROMs?

So I desided to modify my favorite kernel img and give it a try. I used Imoseyon's leanKernel but it should work with any kernel.

How To:
1. Get Android Image Kitchen and extract it to your PC;
2. Open your_favorite_kernel.zip with 7zip and extract boot.img file to Android Image Kitchen folder;
3. Drag and Drop boot.img over unpackimg.bat. Kernel is unpacked and you will see 2 new folders - ramdisk and split_img;
4. Go to ramdisk folder and open default.prop file with text editor. This probably is not necessary but just in case change ro.secure and ro.adb.secure to 0 (zero):

Code:

ro.secure=0
ro.adb.secure=0

5. Get Chainfire's adbd Insecure v1.30, open it with 7zip, in assets folder you will see 3 .png files. Extract adbd.17.png to ramdisk\sbin folder;
6. Delete original kernel adbd file and rename adbd.17.png to adbd;
7. Go back to Android Image Kitchen folder and run repackimg.bat by just click on it. This will repack the modified kernel to image-new.img file ready for flashing;
8. Rename image-new.img to boot.img and replace the original one in your_favorite_kernel.zip by Drag and Drop in 7zip window;
9. Close 7zip, copy modified your_favorite_kernel.zip to /sdcard and flash it in recovery.
10. Enjoy ADB full root access for /system;

Warnings:

I can't guarantee 100% success with this mod. I did this only with leanKernel and it works great, Haven't tried any other kernels so I am note sure how all this will end up. IT CAN SOFT BRICK YOUR PHONE!!! Keep a copy of the original kernel on your /sdcard!!!

Doing this while trying to find the correct tools for proper repack of the modified kernel sometime I was ending up with the phone not booting to Android, goes straight to download mode. Don't panic... Just remove battery, place it back, hold Volume Up + Home + Power buttons booting to recovery. Flash the original kernel and you are back all good.

The usual stuff:

I AM NOT RESPONSIBLE FOR ANYTHING ... bla-bla-bla...

All the credits goes for the developers created the great tools used for this mod.

If you think it's useful fill free to say THEM and me thanks.


http://forum.xda-developers.com/showthread.php?t=2488233

multiple cmd adb java call andriod shell ,AWK cmnd

http://stackoverflow.com/questions/3474318/shell-batch-scripting-to-direct-commands-to-adb-shell

======================

รูปแบบ 

D:\YumYumAndroidTool>(

More?    echo cd sdcard

More?    echo ls

More? ) | adb shell

===================

เราสร้าง ไฟล์ 

D:\YumYumAndroidTool>echo cd sdcard > cmd.txt

D:\YumYumAndroidTool>echo ls -l >> cmd.txt

D:\YumYumAndroidTool>adb shell < cmd.txt

adb shell < cmd.txt

========================

adb shell "cd sdcard;ls -l"

======================

===for dos shell and  bat file

cmd /c "echo foo & echo bar"

D:\YumYumAndroidTool>cmd /c "echo foo & echo bar"

foo

bar

============for dos

cmd /? ดู help

---------------

D:\YumYumAndroidTool>cmd /c if exist abc. (rd /q abc) & echo hello

hello

ถ้า dir abc มี ให้ลบ แลว ทำคำสั่ง echo hello

--------------

echo netsh dump ^&^& pause ^&^& exit>foobar.cmd && start "" /w foobar.cmd && del foobar.cmd

---------------

cmd /c %1 

cmd /c %2 

สร้าง ไฟล์ bat ใสคำสั่งบน เพื่อให้มัน รันทีละคำสั่ง

bat "dir /w" "pause"

----------

Command A & Command B

Execute Command A, then execute Command B (no evaluation of anything)

---

Command A | Command B

Execute Command A, and redirect all its output into the input of Command B

---

Command A && Command B

Execute Command A, evaluate the errorlevel after running and if the exit code (errorlevel) is 0, only then execute Command B

---

Command A || Command B

Execute Command A, evaluate the exit code of this command and if it's anything but 0, only then execute Command B

Using multiple commands and conditional processing symbols

You can run multiple commands from a single command line or script using conditional processing symbols. When you run multiple commands with conditional processing symbols, the commands to the right of the conditional processing symbol act based upon the results of the command to the left of the conditional processing symbol.

For example, you might want to run a command only if the previous command fails. Or, you might want to run a command only if the previous command is successful.

You can use the special characters listed in the following table to pass multiple commands.

& [...]  command1 & command2
Use to separate multiple commands on one command line. Cmd.exe runs the first command, and then the second command.

&& [...]  command1 && command2
Use to run the command following && only if the command preceding the symbol is successful. Cmd.exe runs the first command, and then runs the second command only if the first command completed successfully.

|| [...]  command1 || command2
Use to run the command following || only if the command preceding || fails. Cmd.exe runs the first command, and then runs the second command only if the first command did not complete successfully (receives an error code greater than zero).

( ) [...]  (command1 & command2)
Use to group or nest multiple commands.

; or , command1 parameter1;parameter2
Use to separate command parameters.

========================

Code Debug Card

code debug card ในนี้ ok -->

http://www.capetronics.com/pdf/DC-0020.pdf

http://itguest.blogspot.com/2013/06/code-debug-card-mainboard.html

http://www.bioscentral.com/postcodes/awardbios.htm

http://www.postcodemaster.com/inteldxxx.shtml

รวม Code Debug Card Mainboard

สำหรับช่างซ่อมคอมมือใหม่ที่มีเครื่องมือ Debug Card เป็นตัวช่วยแล้ว บางครั้งอาจจะไม่รู้ว่าค่า Error Code นั้นคืออะไร ผมได้สืบหาข้อมูลและเขียนเพื่อเตือนความจำของตนเองไว้ เพราะไม่ค่อยได้ใช้ตัว Debug Card นี้เช่นกัน นานๆครั้งมาใช้นั้น ค่อนข้างที่จะค้นหาข้อมูลอย่างลำบากเช่นกัน ผมจึงได้รวบรวมข้อมูลมาจากเว็บที่หาข้อมูลได้ ขอขอบคุณเจ้าของข้อมูลด้วยครับ

CODE : ความหมาย

00 : ไม่มีสัญญาณให้เช็ค CPU หรือลองหา CPU ตัวใหม่มาเปลี่ยนดูครับ

01 : CPU TEST รอบที่ 1

02 : CPU TEST รอบที่ 2

04 : TEST Memory รีเฟรช ของอุปกรณ์ ต่าง ๆ 

05 : Key board controller อาจมีปัญหา

07 : BIOS battery อาจจะหมด

0B : TEST cmos checksum

0D : เช็ค VGA CARD Interface

C0 : ทดสอบหน่วยความจำและ slot(ลองฉีด สเปรย์สารพัดพิษดูครับ)

0E : เช็คหน่วยความจำ VGA(ลองหาตัวใหม่มาเปลี่ยนดูครับ) 

11 :อาจมีปัญหาที่ DMA controller

41 : ให้ตรวจสอบ FLOPPY Drive

42 : .ให้ตรวจสอบ HARD DISK

43 : ค้นหาและตรวจสอบ serial และ parallel port

45 : ให้เช็ค Mainboard ว่าเข้ากับ CPU ได้หรือเปล่า เช่น CPU ใช้ FSB สูงกว่าที่ Board รองรับหรือไม่)

FF,D0 : เครื่องปกติ

ไม่มีตัวเลขอะไรขึ้นเลย : BIOS เสีย

ข้อมูลจาก : บทความ IT

CODE ความหมาย

C0-C7 : ลองแฟลชไบออสดู ไม่ก็ แล้วลองตรวจสอบระบบอีกครั้ง บางครั้งแรมอาจติดต่อกับ N/B ไม่ได้

D0 : ลองตรวจสอบไฟ CPU ว่าปกติหรือเปล่า หรือไม่ก็ซ็อกเก็ต CPU ว่าต่อกับ CPU จริงหรือเปล่า

D1-D7 : ลองตรวจเช็คแรม ไม่ก็ ไฟแรม สล็อตเสียบแรมแน่นหรือไม่

90-AD : สลับกัน แล้ว 90 จะดับ แต่จะค้างที่ AD แสดงว่า Data ของแรมไม่สามารถติดต่อกับ N/B ได้ แนะลองใช้แปรงทาสีทำขาความสะอาดที่ช่องสัญญาณของสล็อกตแรมดู ถ้ายังไม่หายก็แสดงว่า Address บางขาของ Ram เกิดการซ็อต ต้องเปลี่ยน N/B

2A : ส่วนมากเป็นที่สล็อต AGP/PCI-E เสียไม่ก็ หรือตัวทรานซิสเตอร์ข้างๆ AGP/PCI-E เสีย แนะนำเปลี่ยนทรานซิสเตอร์ก็น่าจะหาย

75-85 : เข้าไบออสไปแล้วตั้งค่าเป็น Set Default ที่มาจากโรงงาน

00 หรือ FF : ถ้าปรากฏเลขฐานสิบหกตัวนี้ถือว่าเมนบอร์ดปกติ

ข้อมูลจาก : รู้ไว้ใช่ว่า ใส่บ่าแบกหาม

CODE ความหมาย

00 - 04 ตรวจเช็ค CPU & RAM

05 - 06 ตรวจเช็ค CPU & BIOS

07 - 0C ตรวจเช็ค VGA & BIOS

0D - 0F ตรวจเช็ค CPU & MAINBOARD

10 - 1F ตรวจเช็ค MAINBOARD & BIOS & RAM

20 - 2D ตรวจเช็ค CPU

2E - 3F ตรวจเช็ค CPU & MAINBOARD

40 - 49 ตรวจเช็ค MAINBOARD

4A - 52 ตรวจเช็ค RAM & MAINBOARD

53 - 5F Reserved

60 - 6F ตรวจเช็ค MAINBOARD & BIOS

70 - 7F ตรวจเช็ค MAINBOARD

80 - 8F Reserved

90 - A5 Reserved

A6 - AF ตรวจเช็ค MAINBOARD

B0 - B8 ตรวจเช็ค CPU & MAINBOARD

B9 - BF ตรวจเช็ค CPU & MAINBOARD & BIOS

C0 - D4 ตรวจเช็ค MAINBOARD & RAM

D5 - EF ตรวจเช็ค MAINBOARD

F0 - FF ตรวจเช็ค MAINBOARD & VGA

ข้อมูลจาก : Mainboard Service

ขอขอบคุณข้อมูลจากทั้งสามแหล่งครับ

adb command 3 iq5.3 mod2g capture-the-screen

http://stackoverflow.com/questions/13984017/how-to-capture-the-screen-as-fast-as-possible-through-adb
เครดิตจากเวป

มาเพิ่ม Internal storageให้เป็น 2GB กันครับ  iQ 5.3
http://droidfriend.com/forums/index.php?topic=2712.0

Calling Android services from ADB shell

Many android automation recipes contain references to the "service call" command: 

# service
Usage: service [-h|-?]
    service list
    service check SERVICE
    service call SERVICE CODE [i32 INT | s16 STR] ...
Options:
  i32: Write the integer INT into the send parcel.
  s16: Write the UTF-16 string STR into the send parcel.

The command is indeed very useful. But the problem is that the calling "CODES" are android version specific and recipes often get out dated sometimes even after a minor version update. I am frequently being asked to update those codes for my recipes. I decided to share a small bash script I have been using to look up service codes for specific Android versions: 

	#!/bin/bash
	ADBShell () { adb ${2+-s }$2 shell "$1" | tr -d '\r'
	}
	GetAndroidVersion () {
	local ALL_TAGS=$(wget -qO - "$GOOGLE_SOURCE/$REPO/+refs/tags/?format=text" | \
	tr -d '^{}' | cut -d/ -f3 | sort -u | grep -vE -- '-(cts|sdk)-' | grep -v "_r0")
	TAG=${1:-$(ADBShell 'getprop ro.build.version.release')}
	echo -e "ANDROID_SERIAL=$ANDROID_SERIAL\nro.build.version.release=$TAG" 1>&2
	TAG=$(echo "$ALL_TAGS" | grep -- "android-${TAG//./\.}" | head -n 1)
	echo -e "TAG=$TAG" 1>&2
	[ "-$TAG" != "-"  ] && return 0
	echo -e "TAG not valid!\n\nList of valid tags: "$ALL_TAGS 1>&2
	exit 1
	}
	GetServicePackageName () {
	SERVICE_PACKAGE=$(ADBShell 'service list' | grep "\s$1: \[" | head -n 1 | tr '[]' '""' | cut -d\" -f2)
	echo -e "SERVICE=$1\nSERVICE_PACKAGE=$SERVICE_PACKAGE" 1>&2
	}
	GetGoogleSourceFile () {
	#echo -e "\t\E[31mdownloading\E[0m $GOOGLE_SOURCE/$REPO/+/$1/$2" 1>&2
	[ "-$1" == "-" ] && return 1
	wget -qO - "$GOOGLE_SOURCE/$REPO/+/$1/$2?format=text" | base64 -d
	}
	GetAllServices () {
	ALL_SERVICES=$(GetGoogleSourceFile "$TAG" "Android.mk" | tr -d ' \\\t' | grep "\.aidl$" | \
	sort -u | grep -v "^gen:")
	}
	ParseServiceAIDL () {
	GetGoogleSourceFile "$TAG" $(echo "$ALL_SERVICES" | grep "${SERVICE_PACKAGE//.//}\.aidl$" | head -n 1) | \
	tr -d '\n\r' | gcc -P -E - | tr '{};' '\n\n\n' | grep -v ^$ | sed -e '1,/interface\s/ d' | cat -n
	}
	AbortIfExecutableMissing () {
	BIN=($@)
	MISSINGBIN=$(for B in ${BIN[@]}; do [ "$(which $B 2>/dev/null)-" == "-" ] && echo $B; done)
	[ "${MISSINGBIN}-" == "-" ] && return 0
	echo -e "Can't find the following executables: "$MISSINGBIN
	exit 1
	}
	AbortIfExecutableMissing "adb wget gcc tr sed awk cut grep basename dirname head base64"
	GOOGLE_SOURCE="https://android.googlesource.com"
	REPO="platform/frameworks/base"
	GetAndroidVersion
	GetAllServices
	GetServicePackageName $1
	ParseServiceAIDL
	exit 0

view rawget_android_service_call_numbers.sh hosted with ❤ by GitHub

This script checks the Android version of your phone and the java package name of the service you specified as a parameter. Then the script downloads the service AIDL file for your phone's Android version from https://android.googlesource.com and parses it. So obviously it only works for the standard Android services it can find the source code for.

This is how I usually run the script. For example let's find out the calling code for "getCallState()" method of the "phone" service. I usually have multiple phones connected to my system so I need to specify which one to use by setting the ANDROID_SERIAL variable first. If you have just a single phone connected you can skip that part: 

~$ ANDROID_SERIAL=XXXXXXXXXX ./get_android_service_call_numbers.sh phone | grep getCallState
ANDROID_SERIAL=XXXXXXXXXX
ro.build.version.release=4.4.4
TAG=android-4.4.4_r1
SERVICE=phone
SERVICE_PACKAGE=com.android.internal.telephony.ITelephony
    32 int getCallState()

10|shell@android:/ $ dumsys iphonesubinfo2

dumsys iphonesubinfo2

/system/bin/sh: dumsys: not found

127|shell@android:/ $ dumsys iphonesubinfo

dumsys iphonesubinfo

/system/bin/sh: dumsys: not found

127|shell@android:/ $ dumpsys iphonesubinfo2

dumpsys iphonesubinfo2

Phone Subscriber Info:

  Phone Type = GSM

  Device ID = 866389014717292

D:\mobile>adb shell am start http://www.kapook.com

Starting: Intent { act=android.intent.action.VIEW dat=http://www.kapook.com }

D:\mobile>adb shell am force-stop com.android.chrome

D:\mobile>adb shell am start -a android.intent.action.MAIN -c android.intent.cat

egory.HOME

am start -a android.intent.action.VIEW "sms:numberhere" -e "sms_body" "hello"

svc wifi disable