在本文中,我们将给您介绍关于指定android.hardware.faketouch后,应用程序仍需要android.hardware.touchscreen吗?的详细内容,并且为您解答指定app的相
在本文中,我们将给您介绍关于指定android.hardware.faketouch后,应用程序仍需要android.hardware.touchscreen吗?的详细内容,并且为您解答指定app的相关问题,此外,我们还将为您提供关于(OK) how to customize the kernel for your hardware for Android-x86、A Complete Guide to FreeNAS Hardware Design, Part II: Hardware Specifics、adb到android真机,修改handheld_core_hardware.xml 文件内容遇到只读问题、android 4.1 touchscreen driver issue的知识。
本文目录一览:- 指定android.hardware.faketouch后,应用程序仍需要android.hardware.touchscreen吗?(指定app)
- (OK) how to customize the kernel for your hardware for Android-x86
- A Complete Guide to FreeNAS Hardware Design, Part II: Hardware Specifics
- adb到android真机,修改handheld_core_hardware.xml 文件内容遇到只读问题
- android 4.1 touchscreen driver issue
指定android.hardware.faketouch后,应用程序仍需要android.hardware.touchscreen吗?(指定app)
我一直在开发一个应用程序,该应用程序最初在清单文件中没有指定触摸屏要求,因此根据文档android.hardware.touchscreen是假定的.由于该应用程序不需要高级手势,因此带有假触摸屏(android.hardware.faketouch)的设备也应该能够运行该应用程序,因此我将该要求添加到了清单文件中以进行更新.
但是,Android市场仍然将android.hardware.touchscreen列为要求(以及android.hardware.faketouch),而且我仍然无法在市场上的假触摸设备(HTC Wildfire)上找到更新的应用程序.
这些是我指定的权限,要求和库:
<uses-library android:name="com.google.android.maps" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"></uses-permission>
<uses-permission android:name="android.permission.INTERNET"></uses-permission>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.autofocus" />
<uses-feature android:name="android.hardware.faketouch" />
<uses-sdk android:minSdkVersion="4"></uses-sdk>
这是一个问题吗(也许市场记得旧的要求,或者Google Maps库插入了触摸屏的要求),或者在指定假触摸时看到两者都列出是正常的吗?
解决方法:
可能为时已晚,但可能会帮助其他人寻找相同的问题
如果您希望触摸屏功能是可选的,请将其添加到清单中:
<uses-feature android:name="android.hardware.touchscreen" android:required="false"/>
否则,它会根据您的某些代码隐式强制使用触摸屏
(OK) how to customize the kernel for your hardware for Android-x86
http://www.android-x86.org/documents/customizekernel
Overview
The Android build system doesn''t compile kernel on-fly. It just contains a prebuilt kernel binary which will be added to the target image. This approach may be good enough for the arm emulator target, but not suitable for x86 platforms. The x86 platforms have various hardware. The kernel binary and its modules may need to be adjusted at compile time or runtime.This article describes an extra feature of the build system of android-x86 project. That is, the ability to build kernel and modules by a predefined or customized config during the building process.
Compile kernel for Android-x86
Prepare the source tree
We have modify the Android build system to compile a kernel image on-fly. You need to use our repository to get this feature. Read the article GetSourceCode for details.
Build the default kernel
We put a default config for android-x86 in kernel/arch/x86/configs/. To build a kernel image from this config, run
$ make iso_img TARGET_PRODUCT=android_x86
By specifying the TARGET_PRODUCT to android_x86, the build system automatically selects the config android-x86_defconfig to compile the kernel binary and its modules. The binary will finally be generated in out/target/product/x86/kernel, and the modules is put under out/target/product/x86/system/lib/modules/. The final target out/target/product/x86/android_x86.iso will contain the kernel binary and its modules.
You may build the kernel and its modules alone, by changing the goal iso_img to kernel.
$ make kernel TARGET_PRODUCT=android_x86
Build the target kernel
Since donut-x86 we have supported multiple targets, e.g., eeepc, tegav2, ... Each target may has its customized kernel config located in its device definition directory. When you choose a target (by specifying TARGET_PRODUCT or lunch command, see GetSourceCode for details.), the customized kernel config of this target will be used to build the kernel image.Build a customized kernel
Suppose you already have a workable kernel config for you hardware, it''s easy to tell the build system to use your config to build the iso. Just put your config file to kernel/arch/x86/configs/, and run (suppose the name of your config is my_defconfig)
$ make iso_img TARGET_PRODUCT=android_x86 TARGET_KERNEL_CONFIG=my_defconfig
Note you cannot use a kernel config from a normal linux distribution (e.g, ubuntu) for android-x86. You need to enable android kernel features to make it work. See android/configs/android-base.cfg for a list of required configuration options for a kernel to support an Android system. (but removes arm specific options for android-x86, e.g., PMEM)
Customize the kernel configuration
It is never advisable to edit the kernel config file directly, as it may generate faulty configuration (dependencies not met etc.). The correct way to customize the kernel config is (on the top of android-x86 tree)
$ . build/envsetup.sh
$ lunch xxx-userdebug
$ make -C kernel O=$OUT/obj/kernel ARCH=x86 menuconfig
where xxx is a target you chosen. Then copy $OUT/obj/kernel/.config to custom_kernel_config_location.
DO NOT issue make menuconfig in the kernel/ directory directly. If you do so, the build rules may be broken. In this case, try this way to recover it (on the top of android-x86 tree):
$ make -C kernel distclean
$ rm -rf $OUT/obj/kernel
Use a prebuilt kernel
If you have a workable prebuilt kernel binary for your hardware, you can generate the iso with it:
$ make iso_img TARGET_PRODUCT=android_x86 TARGET_PREBUILT_KERNEL=<path to the prebuilt kernel>
Compile kernel for ARM (deprecated)
The kernel build system can also be used to compile kernel for ARM. For example, to compile kernel 2.6.29 for the goldfish CPU of the arm emulator, run
$ cd kernel
$ git checkout x86/android-goldfish-2.6.29
$ cd ..
$ make kernel TARGET_KERNEL_CONFIG=goldfish_defconfig TARGET_NO_KERNEL=
The kernel binary will be generated in out/target/product/generic/kernel.
Set TARGET_NO_KERNEL to be empty is important, otherwise the kernel building steps will be skipped.
A Complete Guide to FreeNAS Hardware Design, Part II: Hardware Specifics
General Hardware Recommendations
I’ve built a lot of ZFS storage hardware and have two decades of experience with FreeBSD. The following are some thoughts on hardware.
Intel Versus AMD
FreeNAS is based on FreeBSD. FreeBSD has a long history of working better on Intel than AMD. Things like (but not limited to) the watchdog controllers, USB controllers, and temperature monitoring all have a better chance of being well supported when they are on an Intel platform. This is not to say that AMD platforms won’t work, that there aren’t AMD platforms that work flawlessly with FreeNAS, or even that there aren’t Intel platforms that are poor choices for FreeNAS, but all things being equal, you’ll have better luck with Intel than AMD.
The Intel Avoton platforms are spendy but attractive: ECC support, low power, AES-NI support (a huge boon for encrypted pools). On the desktop side of things, there are Core i3 platforms with ECC support, and of course there are many options in the server arena. The single socket E3 Xeons are popular in the community, and of course for higher end systems, the dual package Xeon platforms are well supported.
Storage Controllers
LSI is the best game in town for add-on storage controllers. Avoid their MegaRAID solutions and stick with their HBAs. You’ll see three generations of HBAs commonly available today. The oldest (and slowest) are the SAS 2008 based I/O controllers such as the 9211 or the very popular IBM M1015. The next generation of these controllers was based on the 2308 which added PCI 3.0 support and increased CPU horsepower on the controller itself. An example here is the 9207. Both the 2008 and 2308 based solutions are 6Gbps SAS parts. The newest generation of controllers are 12Gbps parts such as the 9300. The FreeNAS driver for the 6 Gbps parts is based on version 16 of the stock LSI driver with many enhancements that LSI never incorporated into their driver. In addition, many of the changes after version 16 were specifically targeted at the Integrated RAID functionality that can be flashed onto these cards. As a result, “upgrading” the driver manually to the newer versions found on the LSI website can actually result in downgrading its reliability or performance. I highly recommend running version 16 firmware on these cards. It’s the configuration tested by LSI, and it’s the configuration tested by the FreeNAS developers. Running newer firmware should work, however running older firmware is not recommended or supported as there are known flaws that can occur by running the FreeNAS driver against a controller with an older firmware. FreeNAS will warn you if the firmware on an HBA is incompatible with the driver. Heed this warning or data loss can occur. The newer 12Gbps parts use version 5 of the LSI driver. Cards using this driver should use version 5 of the firmware.
Most motherboards have some number of SATA ports built in. There are certain models of Marvell and J-Micron controllers that are used on motherboards that have large numbers of SATA ports. Some of these controllers have various compatibility issues with FreeNAS, and some of these controllers also have forms of RAID on them. As a general rule, the integrated chipset AHCI SATA ports have no issues when used with FreeNAS, they just tend to be limited to 10 ports (and often far fewer) on most motherboards.
Hard Drives
Desktop drives should be avoided whenever possible. In a desktop, if an I/O fails, all is lost. For this reason, desktop drives will retry I/Os endlessly. In a storage device, you want redundancy at the storage level. If an individual drive fails an I/O, ZFS will retry the I/O on a different drive. The faster that happens, the faster the array will be able to cope with hardware faults. For larger arrays, desktop drives (yes, I’ve seen attempts to built 1PB arrays with ZFS and desktop drives) are simply not usable in many cases. For small to medium size arrays, a number of manufacturers produce a “NAS” hard drive that is rated for arrays of modest size (typically 6-8 drives or so). These drives are worth the additional cost.
At the high end, if you are building an array with SAS controllers and expanders, consider getting the nearline 7200 RPM SAS drives. These drives are a very small premium over Enterprise SATA drives. However, running SATA drives in SAS expanders –while supported– is a less desirable configuration than using SAS end to end due to the difficulty of translating SATA errors across the SAS bus.
Josh Paetzel
iXsystems Director of IT
<< Part 1/4 of A Complete Guide to FreeNAS Hardware Design, Purpose and Best Practices
Part 3/4 of A Complete Guide to FreeNAS Hardware Design, Pools, Performance, and Cache >>
adb到android真机,修改handheld_core_hardware.xml 文件内容遇到只读问题
我通过adb shell 将Android设备连接到PC之后,想vi修改里面的文件内容,提示文件是只读文件,查看权限-rw-r--r-- root ,然后我想修改权限为777,执行
chmod 777 handheld_core_hardware.xml 结果就提示如下信息:
Unable to chmod handheld_core_hardware.xml: Read-only file system不知道怎么回事?该怎么办?用了前辈上面的命令,
|
mount -o remount rw / |
shell @android :/ $ mount -o remount rw /
mount: Operation not permitted
怎么回事呀?求指点~
我就是想在PC端修改android真机中的handheld_core_hardware.xml文件,怎么办呀?有没有知道啊?望指点!先谢过了~
|
|
android 4.1 touchscreen driver issue
@雨焰 你好,想跟你请教个问题:
我最近在调试android4.1的touch screen 。但是遇到驱动编译完成后直接连接触摸屏getevent打印信息正常,但不能解锁/用户界面触摸就是没反应,我查看其他可用的touchscreen driver 但发现也没有添加idc文件,但是却能正常工作,不知道你是否知道原因,谢谢~~
关于指定android.hardware.faketouch后,应用程序仍需要android.hardware.touchscreen吗?和指定app的介绍现已完结,谢谢您的耐心阅读,如果想了解更多关于(OK) how to customize the kernel for your hardware for Android-x86、A Complete Guide to FreeNAS Hardware Design, Part II: Hardware Specifics、adb到android真机,修改handheld_core_hardware.xml 文件内容遇到只读问题、android 4.1 touchscreen driver issue的相关知识,请在本站寻找。
本文标签: