Showing posts with label Samsung. Show all posts
Showing posts with label Samsung. Show all posts

Epic4G Bootstrap

Looking for an Epic4G kernel that has Clockwork Recovery and ROM Manager support built in? Several devs banded together to create a bootstrap for this device. In no particular order:
  • Tanimn: ext4 support (donate)
  • DRockstar: rfs/dual support (donate)
  • rjmjr: lending me a phone
You can support my work grab the kernel flasher off of the Android market for $2.99.
Or you can get it free from the download link here on my site.

Samsung Mobile Innovator: A Step in the Right Direction

Windows Mobile developers that have used the Windows Mobile Unified Sensor API may know that painful reverse engineering process took place to add support for Samsung and HTC phones. This is because no phone manufacturer has released the internal API specifications for their device sensors!

However, Samsung recently released the SDK for their Light Sensor and Accelerometer on their new Samsung Mobile Innovator website. I don’t have a Samsung phone available at the moment, but the SDK looks pretty straightforward! And although it would have been ideal if Samsung had officially supported the Sensor API, this is a step in the right direction! A published API is better than no API. Hopefully HTC follows suit!

Here’s a snapshot of the managed bindings that were included with some of the SDK sample code:

namespace SamsungMobileSdk
{
    public class Accelerometer
    {
        public struct Vector
        {
            public float x;
            public float y;
            public float z;
        }

        public struct Capabilities
        {
            public uint callbackPeriod; // in milliseconds
        }

        public delegate void EventHandler(Vector v);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetVector")]
        public static extern SmiResultCode GetVector(ref Vector accel);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetCapabilities")]
        public static extern SmiResultCode GetCapabilities(ref Capabilities cap);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerRegisterHandler")]
        public static extern SmiResultCode RegisterHandler(uint period, EventHandler handler);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerUnregisterHandler")]
        public static extern SmiResultCode UnregisterHandler();
    }
}

I’ll be adding support for the official Samsung API to the Sensor API shortly.

Unified Sensor API now supports the Omnia Light Sensor

Around a month ago I got a tip from an anonymous reader (I think it's a Samsung developer) on how to access the Samsung's light sensor. The tip seems to work correctly [0], so I added support for that sensor in the Sensor API.

I ended up having to refactor the API a little to support the Samsung light sensor transparently: the changes are similar to the ones I made a few months ago for transparently creating the proper IGSensor implementation on a given device.

So, the change log:

  • HTCLightSensor is now a private class.
  • SamsungLightSensor is a new private class.
  • Refactored HTCGSensor and SamsungGSensor to derive from GSensorBase which inherits from PollingSensor. This change was made to consolidate much of the sensor code.
  • Instead of creating an HTCLightSensor or SamsungLightSensor explicitly, developers should use the new LightSensorFactory.CreateLightSensor method to get the appropriate ILightSensor object for the phone the application is running on.

Here's the link for the updated API and code samples.

I'll be recompiling Klaxon shortly to accommodate the new changes.

[0] It looks like the way this is done is by reading the backlight intensity value, rather than actually reading the light sensor. The Omnia sets the backlight value based on that reading.

Sensory Overload for the Samsung Omnia

SensoryOverload

After fixing up the OpenGL ES wrapper to work with Vincent 3D, porting this game to the Omnia was simply a recompile!

Since the Omnia does not have a "Nav" wheel, click the center button to shoot a bullet, and "swipe" it to use the special spray attack. Just a reminder this isn't meant to be a full featured game, just a demo on how to write 3D games. :)

Sensory Overload CAB file.

Source code to Sensory Overload.

Klaxon - Accelerometer/G-Sensor Enabled Alarm Clock now supports the Samsung Omnia!

Klaxon2ScreenshotKlaxon2EditSmall Klaxon2SettingsKlaxon2AlarmScreenshot

Samsung Omnia users will be pleased to hear that Klaxon now supports their accelerometer. That's the only change in 2.0.0.18. Click here for the Klaxon CAB setup file.

Using Samsung Omnia's Accelerometer/G-Sensor from Managed Code

Many months ago, I wrote an API to access the HTC Touch Diamond's Accelerometer from managed code. Those who investigated the code a bit deeper probably noticed that I had stubbed out an interface, IGSensor. I did that in anticipation that many Windows Mobile devices in the coming months would include an accelerometer. It turns out I was right. The idea behind the IGSensor interface was to provide a generic unified API that a developer could use to access the accelerometer of any device without having to worry about which device it was.

Anyhow, I'd gotten several requests to investigate the Samsung API, if there was one. Not an Omnia owner myself, I wasn't particularly motivated. Then yesterday, one of the requestors informed me that Spelomaniac from modaco.com had figured out how to access the Samsung Omnia's accelerometer.

We happened to have an Omnia at my workplace, Kiha, so I grabbed that, and ported the code so it was supported by my API. So yeah, it's all working!

I highly recommend that all developers to download the updated API and make the minor changes necessary so that Omnia users can make use of the HTC Touch Diamond accelerometer applications! Here are the new breaking changes in the API:

  • HTCGSensor is now a private class.
  • SamsungGSensor is a new private class.
  • Instead of creating a HTCGSensor or SamsungGSensor explicitly, developers should use the new GSensorFactory.CreateGSensor method to get the appropriate IGSensor object for the phone the application is running on.
  • IGSensor is now IDisposable. Developers should Dispose of the object once they are finished using it. Not doing so may leave resources or a thread hanging and the application may fail to exit.

That's it! The code changes you need to make should only take you a few minutes.

Click here to download the new Windows Mobile Unified Sensor API.

I'll be making the changes necessary to Klaxon this weekend so it runs on the Omnia. :)

Here is the original C++ code I for the HTC GSensor emulator in case you are interested. I would not recommend using the HTC Accelerometer emulator, because it does not support Orientation Change notifications through the Windows registry.