I had a problem recently with some devices after I upgraded to SDK Tools r16 from SDK Tools r11.
I found out it was texture related, now looking back the APK files I created with SDK Tools r11 contain exact copies of the textures in the raw file. But the APK files created with SDK Tools r16 contain some differences at the byte level, I can't see any difference, no difference in colour depth either, but whatever has happened to them causes problems loading on PowerVR GPU devices.
JPG and BMP files are not altered.
Does anyone know what might be causing this and how I can get a raw file to stay raw?
Edit: Looking at the files inside Notepad++ I see "iCCPPhotoshop ICC profile" is removed from the header. There may be other changes.
Edit2: Looking at the properties in windows explorer the raw one says "Attributes A" and the APK one says "Attibutes N". It's definitely stripping/changing information.
Edit3: I meant SDK Tools Revision XX not API XX
I don't know why anyone thought this was a good idea but Android does some sort of compression on PNGs. See here for one guy's experience with it. I'm not sure if API 16 does something different from API 11, but this behavior has been there since way before 11. As to how to fix this behavior, I suspect that renaming your resource might help. Try naming it whatever.mp3 instead of .png and see if that fixes it.
Related
This is the first time I am building yocto images. I first read this list of images in the documentation and selected core-image-sato-dev, since I wanted to have some image where I could do some hello world .
The doc says
core-image-sato-dev: A core-image-sato image suitable for development
using the host. The image includes libraries needed to build
applications on the device itself, testing and profiling tools, and
debug symbols. This image was formerly core-image-sdk.
Something that I misunderstood was that the development is using the host
Yes, I cannot find gcc in /usr/bin. So this image does not have the c compiler (it has make though)
So what should I do? Is there a way to add it? Or should I go for core-image-sato-sdk??
What exactly does this imply?
core-image-sato-sdk: A core-image-sato image that includes everything
in the cross-toolchain. The image also includes development headers
and libraries to form a complete standalone SDK and is suitable for
development using the target.
GCC or any other compiler is not meant to be part of that image. As the quote from the docs you've provided says, The image includes libraries needed to build applications on the device itself.
All core-image-sato-dev does it inherits core-iamge-sate and adds dev-pkgs to IMAGE_FEATURES which ships development packages.
What you're looking for is tools-sdk in IMAGE_FEATURES.
My phone’s Android has under /system/lib/hw the following files among others:
sensors.exynos4.so
sensors.smdk4210.so
Those dynamic libraries are somewhere in the chain for sensors like compass, gyroscope and ambient light.
The first file (sensors.exynos4.so) comes from the the distribution itself (running CyanogenMod 10.1 for i9100), the second (sensors.smdk4210.so) is what I fished out of the stock ROM for my phone (SHW-M250S, “Korean S2”, a variant of the i9100) and copied it there.
Question1: What is using those files?
Doing an ldd (actually a readelf or objdump) over all binaries and libraries in the system did not reveal any users of those files. My conclusion: someone has to load them like plugins during runtime after dynamic linking! But who/what? (source code file name or link to a code browser, please)
The users of those libraries switched from the first to the second without any configuration (after I placed it there). I would like to dig into this mystery.
Question2: Where is the source of those files?
The files contain (at least) the configuration of the sensors (like it’s positioning on the board, value ranges and steps). I want to generate a correct one for my phone. If I have the source of both, it would be easy to do so. – With only the CyanogenMod version, I can at least guess the necessary corrections.
Notes:
No guesswork answers.
If part of your answer is “binary”:
point me to the blobs in the CyanogenMod source or the script that pulls them.
follow the chain to the first open source library/program which uses them.
The questions are not really device specific. – Answer with any device in mind, the situation should be similar (AOSP, AOKP, CyanogenMod, ...).
They are binary blobs.
Has the sensors.exynos4.so and other proprietary blobs
https://github.com/chris41g/proprietary_samsung_epic4gtouch/tree/master/proprietary/lib/hw
The blobs can be pulled from a running device with the extract-files script which reads a list of the proprietary files from proprietary-files.txt in the project for whatever device you are building CM for.
Try googling the files maybe or looking through the CM tree or their wiki.
The HAL is the Hardware Abstraction Layer is the interface that is used to get sensor data from the kernel/device drivers back to userspace.
Found this pdf which discussed building the Android HAL but for a different device and the output described there is
After having successfully downloaded and compiled the Android sources, the user can compile and add/substitute the sensor HAL library.To do this, copy the sensor HAL library folder in the android sources path, usually located in:
[Root Android Sources]/vendor/[vendor name]/[boardname]/
Before the build operation of the library, the user must initialize the Android environment:
[Root Android Sources]$ source build/envsetup.sh
[Root Android Sources]$ lunch [target board]
It is now possible to build the library; just launch the “mm” command in the HAL folder. The result of this process is a dynamic library located in:
[Root Android Sources]/out/target/product/[board name]/system/lib/hw/sensors.[board name].so
In the case of the sensors, the SensorService loads the HAL so it can talk to the sensors.
HAL
Building HAL
Update:
Did some more digging around my CM tree
device/samsung/i9100 contains an Android.mk file that builds sensors.exynos4.so.
The .mk file specifieds the module as
LOCAL_MODULE := sensors.$(TARGET_BOARD_PLATFORM) which is set in
device/samsung/galaxys2-common/BoardCommonConfig.mk.
There is source in device/samsung/i9100/libsensors for this device. Looking at device/samsung/i9100g however there is no libsensors and that device requires running the CM scripts to pull the blob from a running device so the availability of source still varies based on device.
Also just an observation that the BoardConfig sets some values to smdk4210.
I can’t answer yet what uses those files, but the source for sensors.*.so is nice to navigate to in CyanogenMod:
Each supported device has a wiki entry which points to the github repo (e.g. i9100 source). There you find additional repositories in cm.dependencies which together cover what you need to build CM for the device in question (e.g. the kernel, common files shared among a group of devices, ...).
In case of the i9100, we can stay in the root repository. In libsensors/Android.mk we see that sensors.<ro.product.board>.so is produced by the files in this directory. The source is all there (for the i9100 device), except libakm.so (binary, according to ../proprietary-files.txt), which is dlopen()ed in AkmSensors.cpp. libakm.so is used for enabling and disabling some sensors, but also creates /dev/input/eventX, a virtual input device reflecting three of the sensors available (compass, acceleration, orientation). (I don’t know how the kernel “runs” virtual devices.)
(sensors.*.so is the Hardware Abstraction Layer. – For the i9100 it handles some /dev/input/event* devices. I didn’t check the kernel for details of those...)
Is it possible to build content for MonoGame 3.0 without having to install Visual Studio 2010 and XNA 4.0?
The content I have to build is:
3D models
textures
sprite fonts
I am aware that there exists MGCB, but before I try and use it I need to know if it is reasonably reliable for what I need it to do.
I'm no expert in this area, but I noticed you don't have an answer yet so I'll try my best.
Having Visual Studio and XNA Game Studio 4.0 installed will allow you to create Content projects that can compile your content into XNB files. Those XNB files can be used in your game without Visual Studio. You can use Xamarin Studio instead.
However, it's also possible to use some content directly. For example, you can use raw PNG files instead of compiled textures and you can build your own system for fonts. I'm not sure about 3D models.
I can't vouch for MGCB but I've read that the MonoGame team are currently developing the content pipeline. If it's not working now it probably will be in the not so distant future.
So yes, it's probably possible.
Just some helpful links. I don't know if the MGCB is finished or completed. I say that because i though i saw a todo list some where on their Git repo. I could be wrong about that.
https://github.com/mono/MonoGame/wiki/Tutorials:-Installing-Prerequisites-on-Windows
http://www.monogame.net/documentation/?page=MGCB
docs on git say build from source
https://github.com/mono/MonoGame/wiki/MonoGame-Content-Processing#building-monogamecontentpipelineprocessors
Video shows how to build MGCB from source.
http://youtu.be/ultZwdGizqM?t=5m57s
I have downloaded openframeworks from Github. I can run all the samples but if I am trying to run opencv example given in openframeworks. Its not working, showing 44 errors and errors are not common too. I think there linking files are also missing in github. Do you have any idea why only opencv example cant get executed ?
In, for example, iPhoneFaceSamplesSomething some files are missing that you can get from other parts of the project (jpg, xml) or just ignore (png). You get a ton of warnings because they added OS X libs which XCode ignore, no big deal. And then some libs are missing for the iPhone like opencv highgui and some other. You should try to get them from somewhere else or compile them yourself. The project definition is a bit messy, you can also file a bug in github.
actually the answer to this is that the ofxOpenCv examples only work when run on the actual device. ofxOpenCv doesn't work in the simulator on iphone currently.
Check the read me file for includes. Often times OF addons have dependancies that are not included in the download.
Also another thing that will get you sometimes is when you're running the incorrect profile on your system. Like OSX 10.5 instead of OSX 10.6. Also fiddle with the release and debug options(switch back and forth), that will often help (I know it sounds hack-ish).
I'm trying to setup a library for simulator or device building and everywhere I see explains that SDKROOT should expand to a /Developer/Platform/<>/SDKs/<>/, where <> is filled in by your project settings.
Many links on the internet explain that SDKROOT will expand to a path, but the newer versions of XCode, SDKROOT expands to "iphoneos2.2.1" - which isn't nearly as helpful (for this task).
Clearly enough if you look at apples documentation, the behavior changed:
http://developer.apple.com/mac/library/DOCUMENTATION/DeveloperTools/Reference/XcodeBuildSettingRef/9-Revision-3.1/history.html
I confirmed the change by looking at some older documentation on my mac.
Any thoughts on how to achieve similar functionality in the latest XCode builds? My end goal is to link to a static library in platform independent ways. The header files differ on each platform, so building a fat-static library doesn't solve the problem.
In Xcode 3.2.1, it looks like SDK_DIR contains the path that used to be in SDKROOT.
I can't find documentation mentioning SDK_DIR anywhere. The Behavior of SDKROOT clearly changed at some point. It used to expand to a full path and now it simply expands to a short form like "iphoneos4.3". I can't find anything documenting this behavior change though and the above link is dead.
On experimenting SDKROOT is the right thing to use. It looks like it expands to the short form "iphoneos4.3" but in reality it expands to the full path at build time. I think Xcode just shortens it for display purposes, which is confusing.