The Android ION Memory Manager

Lately theres been quite a bit of discussions about Android "ION". What exactly is ION? Is it just some fancy name or is there more to it?

Lets talk about some history of Android first.

Since the very beginning, vendors of Android devices like HTC, Samsung or Motorola all use different System on a Chip (SoC) solutions from Qualcomm (MSM/Snapdragon), Nvidia (Tegra) and TI (OMAP). Each SoC has its own kernel drivers for managing memory buffers (chunks of scratchpad memory) used by Graphic Processing Unit (GPU), Audio processing, and Camera Stills and Video processing.

Every vendor had their own version of memory management, such as PMEM for Qualcomm, NVMAP for Nvidia and CMEM for TI - private memory not shared with anyone else. Each Android graphics, audio and camera libraries had to be customized to work with each of the SoCs own flavour of memory management, which makes it a nightmare for the Android Maintainers to maintain the fragmentation and compatibility issues abound. However, this was the case for all pre-Ice Cream Sandwich OS like Froyo, Gingerbread or even Honeycomb.

For Android 4.0 (aka Ice Cream Sandwich), Google was finally fed up with the private memory manager structure and decreed that all newer devices with Android 4.0 native should use the new, so called "ION" memory manager.

So what is exactly the Android ION?

In a simple words, Android ION removes ARM specific dependencies. The ION memory manager provides a common structure for how memory will be managed and used by GPU, Audio and Camera drivers. Common functions are:

• memory allocation / de-allocation
• Direct Memory Access Pools
• user-space (Android libraries) memory passing to/from kernel space

With these common functions and structures defined, kernel drivers from each SoC manufacturer needed to rewrite their drivers to be compatible with Ice Cream Sandwich. Once the drivers adopted to the new common structure, the graphics, audio and camera libraries can now be more generic and could care less about the nitty-gritty details of how different SoC vendors drivers worked.

It was painful at first, but it was a necessary move for Google to impose to all the SoC vendors. Now looking back, this new ION manager enabled manufactures and third party Android projects (like Cyanogen-mod) to quickly bring up newer Android releases for various devices and also reduce the "hidden" Android fragmentation.

If you want to take a look at the code of the ION memory manager, please visit faux123 github - MSM ION

I hope you enjoyed my first Kernel GeekTalk series... more to come soon!

Have any questions or comments? Feel free to share! Also, if you like this article, please use the media sharing buttons (Twitter, G+, Facebook) under this post!

Read More..

Virtual SD card on Android

Since Android Honeycomb, Google changed the way to manage internal memory on Android devices. Before Honeycomb, every user had one separate partition on his device called userdata (/data), where he could install applications and where all user settings were stored (home screens, applications data, contacts, and all the rest you loose after doing so called "full wipe" on your device). Apart of userdata partition, all Android devices had microSD card slot to save pictures, movies, backups etc.. Now it looks completely different, but lets start from the beginning. There are several approaches to this subject, Ill present here all those I am aware of.

• userdata partition + microSD card

This is the mentioned above pre-Honeycomb approach. There is userdata partition, where you can install all your applications and you also have a possibility to insert microSD card. Nothing more to explain. Only devices running Android Gingerbread and older versions have such configuration, so its getting less and less popular.

• userdata partition + virtual SD card on userdata partition

This is the new approach presented for the first time in Honeycomb. Instead of having /data partition together with expandable microSD card slot of any capacity, Google decided for something different. Instead, /data partition became very large (16/32/64 GB) and inside you can find /data/media folder that contains all the files you can see as your SD card content. How does it work? Without too much technical explanations, there is so called fuse tool which emulates media folder inside userdata partition as a separate storage device. As a result, after connecting smartphone to the PC you can browse the content of /data/media location, so if it was a microSD card. The biggest downside of such approach is a high risk of loosing all your virtual SD card content in case of any serious /data partition failure. Also, such partition cant be formatted with mkfs.ext4 without loosing content of virtual SD card, because you cant format device partition just partially. You can use e2fsck tool to check for potential errors, but sometimes partition format is the only way out. How does "full wipe" work then? Well, its a little bit complicated. First of all, you cant format mounted (in use) partition. You need to unmount it first. Once unmounted userdata partition, you cant flash any ZIP file from inside recovery, because ZIPs files are stored on virtual SD card (/data/media) and remember that userdata partition is currently unmounted, because we want to format it. There is a workaround for it - you can run mkfs.ext4 from inside /cache partition or you can use command prompt. Now, what if you need to remove the whole content of your userdata partition, but you want to keep virtual SD card content at the same time? There is a workaround for this as well, but instead of formatting entire partition, you need to remove all files excluding /data/media location. Example:

#!/tmp/bash
# Remove content of /data partition excluding data/media files
cd /data
FILES=(*)
for i in *; do
if [ "$i" != "media" ]
then rm -R "$i"
fi
done

This way you can sort of wipe userdata, but it doesnt format the partition, so you cant fix broken file-system with it.  Why this point is the longest one? Because it took me quite a few words to explain the relation between virtual SD card and media folder on userdata partition (/data/media). So basically, what you read here applies to every configuration with virtual SD card emulated on userdata partition.

• userdata partition + virtual SD card on a separate partition

This approach is not very popular, and its a shame because it seems to be much more practical rather than the previous one. Instead of emulating SD card from userdata partition, there is a separate, large partition with vFAT file-system. That means you can format your userdata partition anytime you want without loosing content of your virtual SD card, or from inside custom ROM, because userdata can be freely unmounted. The only device Ive seen so far with this approach was HTC One X.

• userdata partition + virtual SD card on userdata partition + microSD card

This seems to be the most desirable solution for many Android users. It works similar to approach described in the second point, so everything I wrote about /data/media is valid here as well. However, every user have the ability to insert extra microSD card inside his device, so he can easily backup virtual SD card to microSD card or format userdata partition without loosing all pictures etc. (if previously stored on microSD card). This is the most common configuration for Samsung devices. But having removable microSD card is not only an advantage. First of all, any kind of microSD card (even SDHC) will be always slower than internal eMMC memory. It depends on many factors like card speed (class 2, 4, 6, 8 or even 10), on-board controller, I/O scheduler and more. Secondly, microSD card damage risk is higher then damage risk of internal eMMC memory. Out of question is the benefit to expand the memory with 64 GB microSD card, but its definitely the minority of power users, who are buying large capacity cards. For the vast majority of users, internal memory with 32 GB capacity is more then enough to store their favorite music or pictures.

• userdata partition + virtual SD card on a separate partition + microSD card

This approach is theoretically possible, but personally Ive never seen device with such combination. For me, this is the best combination. You have possibility to use external microSD card and virtual SD card is not a part of userdata partition, but it has its own, separate vFat partition. Such configuration gives you control over all your data and possibility to manage it however you want.

Do you have any questions or want to share some opinion? Please leave a comment below! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) down this post!

Read More..

The Meenova Micro SD Card Reader for Android

A few months back I decided to pledge $12 US to a Kickstarter Project for a miniaturised USB card reader for Android smartphones. The idea looked promising, and I had a spare $12, so I took the gamble, and this week it paid off. Through the post I received the dividend on my investment. Ill follow up this mini-review with some details on performance once I can get hold of a class 10 card, but for now here are some first impressions and opinions.

The concept of USB OTG (on-the-go) storage is a good one, especially for the increasing number of us of us whose favourite phones dont have an SD card slot. However, one of the big issues with the regular arrangement for OTG is the need to carry a male-female adapter cable and a card reader or memory stick around in addition to the telephone. Doing away with this inconvenient clutter was really what attracted me to the idea of the Meenova reader.

I knew that a tiny, almost weightless device, which clips to my keyring, but which can take exchangeable micro SD cards at least up to 64Gb, would be worth $12 to me just for the convenience. The Meenova reader ticks all those boxes at around 2cm square by 8mm thick and weighing in at only 3 grammes.

Unboxing the Meenova

The reader arrived by mail, safe in a protective envelope, direct from the manufacturing facility. US customers receive theirs via USPS, the rest of the world via Hong Kong Post. Inside the envelope the reader was neatly packaged, and the pack included the reader, a USB adapter for lap/desktop connectivity, and a keyring clip.

 

All the items were well made and well finished. The only exception was the tiny split ring for the keyring adapter, which was quite flimsy, but that was such an insignificant part of the package that I just replaced it with a better one for five cents. The cap clips onto the reader with a satisfying and tight click, and the reader is securely held. 

That led me to thinking that instead of hanging the reader from my keyring, I should hang the cap from the ring and clip the reader in/out of it as I used it. I punched a small hole in the cap, threaded the tiny keyring through it, and I am very happy with the modification. 

N.B. - Later Edit 

Do NOT hang the reader on your keyring as I described above. My reader came unclipped twice today and I almost lost it !! Use the tag provided on the body of the reader and pass the spring clip through that. Only use the ring to hang the cap from the clip when the reader is in use.

Getting To Grips with the Meenova

Having got it all ready to use, my next step was to rummage in the spares bin. Luckily I found an old 8Gb class 4 SD card to use for the first test. I slotted it into the reader, plugged the reader into the USB adapter and plugged all that into my trusty iMac.

Partitioning and formatting the card was quick, easy and there were no issues.  A nice touch is that USB connector on the reader is mounted in a raised, transparent, plastic "plinth" and from inside the casing a blue LED flashes to indicate any activity.

The Meenova is actually much smaller than it appears here

My first test was to load up my entire photo library from iPhoto to see what would happen. 2 Gb was a heavy enough load, and during the loading process I also deleted around 400 of the photos from the card during the load to see if that caused any issues. The process took a while, but there was no noticeable slowdown during the deletions and no data dropouts or corruption.

Following the successful upload I unmounted the device and plugged it into the USB port of my HTC One. The One immediately reported "Preparing USB storage, Please Wait" and then "USB storage is ready" which popped up almost too quickly for me to take the screen shots.

ES File Explorer, showed me that the USB was mounted automatically by the OS at the mount point /mnt/usb. On opening, Explorer already had the USB folder open and I was able to examine the contents just as I would any other part of the file system.

The next step in this little test was to open Gallery and look for the photos I uploaded. They had already been found by the Gallery app and the app was in the process of making them available. Once the photos folder had been opened in Gallery, the photos themselves did take some time to appear, but until I can get hold of a faster card I can only speculate on whether this was caused by the cheap, slow card, the reader, or the OTG/USP processing in the phone OS.

Gotcha !!!

After playing with it for a while I was ready to hang the reader back on my keyring and drop my One into its slip case ... That was the only point at which I had an issue with the setup. In my haste, I just pulled the reader out of the USB socket and immediately received the notification "USB Storage unexpectedly removed" ...

Oops ... My Bad ... I had forgotten to unmount before removal!

I was only reading from the card so on this occasion it wasnt a painful experience, but no excuses ... some cards can be very sensitive to superblock corruption so its never a sensible thing to just pull them out without first unmounting, and definitely not advisable following a write to the card.

Just to make sure I knew what to do in future, I reinserted the reader and went in search of the unmount action. I have to admit, I was naively expecting a bar in the notifications or settings pull-down with some obvious wording such as "USB/OTG storage - Click to unmount" ...

No such luck ... I eventually found the action buried in the basement !! ... Its actually in Settings->Storage->USB Storage->Unmount USB Storage.

For the sake of user convenience, I think there is a good case for smartphone manufacturers to do some rethinking about where that action should be placed. In my opinion, it belongs in a much more prominent position.

Third-Party Apps and the Meenova

Because of that one thing, I went in search of an OTG/USB third-party app to see if I could make the unmount a little more convenient. I tried two (see *** footnote) and both worked well. However, both of them were designed to manage the mount and unmount themselves. That is, they are set up to create a mount point and mount to/unmount from that point. When using these apps on the HTC One, the OS native mount is maintained in addition to the ones set up by the tool, so a final unmount will still need to be done from within the settings page.

If you have a phone with an OS which automatically mounts the OTG/USB storage, then dont bother with third-party apps. Just be sure you know how to unmount the device. If, on the other hand your OS doesnt automount the storage, but you have an OTG-aware kernel, then these third party apps can make your use of OTG devices easier.

OTG Compatibility

There is a list of known compatible devices on the Meenova web site, but in this rapidly changing world, the list may not be complete. In hard terms, the device is only a micro card reader, and the chipset is the same one that can be found in many regular readers, so the rule of thumb is that if your phone works with a cable and memory stick, either with native or third-party software, then the chance is good that it will work with a Meenova Reader as well.

On the general subject of OTG compatibility my advice is for you to research your phone carefully before buying anything. Not all versions of Android support OTG and manufacturer support can also very variable, even between model ranges from the same company. Dont just assume that because your phone is fairly new and your Android is 4.x then it will have OTG. Check it out.

Conclusion (for now)

Overall I am already satisfied with my $12 investment, and at this point I feel that I can recommend this device to anyone looking for a compact, handy, OTG/USB storage solution.

In Part Two (coming soon) I will take a closer look at the Meenova readers performance with music and video files, and I will try to run a set of timing comparisons using Class 4 and class 10 Micro SD cards.

Have any questions or comments? Feel free to share! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) below this post!

---

*** The OTG Storage managers I tested were:

USB Storage Manager by Goprasoft
USB OTG Helper (Root) by Ray of Light

As for Meenova the company, the Kickstart project seems to have been a great success. Plenty of cash was raised to get the project onto a stable footing, and I have yet to read a negative comment about either the Meenova reader or the guys who set it all up. The initial seed stock has now been dispatched to all the original backers, and the company are now taking pre-orders for the next batch of devices.

Read More..

Runtastic on Android Wear

By Austin Robison, Product Manager, Android Wear

Fitness apps make  great additions to Android Wear. Let’s take a look at one of our favorites, Runtastic. Runtastic is a fitness app that lets you track your walks, runs, bike rides and more. With Runtastic on Android Wear, youll see your time, distance, and calories burned at a glance on your wrist. You can also start, stop and pause your activity by touch. Tuck your phone away in a pocket or backpack and do everything on your watch.

Its challenging to build user experiences that really come alive on Android Wear because its such a new type of device. Runtastic does a great job of showing the right information and providing just the right controls on the screen on your wrist. Lets dig into some of the Android Wear platform features that Runtastic uses to make such a great user experience.

Voice Actions

Android Wear enables developers to launch their activities with voice. Runtastic responds to “Ok Google, start running” by beginning to track a session and displaying a card with your total time. This means you can start exercising without needing to pull your phone out of a pocket or arm strap. Android Wear is all about bringing you useful information just when you need it and enabling users to quickly and easily take action.

Responding to platform voice intents on Wear is as simple as declaring a standard intent filter to start an activity.  For example, to launch your activity for the “start running” voice action, add the following to your activity’s entry in your AndroidManifest.xml:

<intent-filter>

   <action android_name="vnd.google.fitness.TRACK"/>

   <category android_name="android.intent.category.DEFAULT"/>

   <data android_mimeType="vnd.google.fitness.activity/running"/>

</intent-filter>

Custom Cards

Once a user has started a run, Runtastic inserts a card in the stream as an ongoing notification to ensure it is ranked near the top of the stream during the activity. This card uses the setDisplayIntent() function to display custom UI. It provides quick, glanceable information, showing your activity time. Cool!

When the user swipes to the right of the card to expose its actions, we see some quick and easy to understand options; following the Android Wear style guidelines means that Runtastic has a familiar UI and feels like a natural extension of the watch. There are actions for pausing, stopping, and an action to see more details on the run.  This action launches a full screen Activity where Runtastic draws a completely custom layout.

You’ll notice this data updates live; Runtastic makes use of the Wearable Data Layer API in Google Play Services to synchronize data between the phone and the watch. Its an easy to use API for syncing data between your devices.

Background Services

When a user finishes their run, Runtastic presents them with a special summary card that appears only on the watch. In this case, the notification is generated directly on the watch by a Service. This Service uses the Data Layer to receive information about the completed activity from the phone to the watch, including an image of a map of the user’s run generated through the Google Maps API.

To show that information, the app uses Android Wear’s NotificationManager, which functions just like the NotificationManager on a phone or tablet, except that instead of creating notifications in the pull-down shade, they appear in the stream.

Runtastics implementation on Android Wear is a perfect example of how to take advantage of wearables to make something truly useful for users. For more information on these and other great platform features, please see the developer documentation.

For more inspiring Android Wear user experiences, check out this collection on the Play Store!

Posted by Mano Marks, Google Developer Platform Team

Read More..

How to Fix no access to the virtual SD card after Android Lollipop update

This solution is based on the experience with some HTC and Nexus devices, however it will work on any device running Android Lollipop or newer/older Android OS with SELinux (Security-Enhanced Linux) kernel security module.

Whats the problem? Sometimes you might not be able to access the content of the internal userdata memory, also known as "virtual SD card" - located as /data/media/0 on the userdata partition. The "bad" workaround is to boot the device in a recovery mode and gain the access to all files from there, but this doesnt solve the problem at all.

Repair Process
Note: root required!

1. Download this mini-sdk package and extract it to c:mini-sdk
2. Connect your device to the PC
3. Start up the device normally, wait until system is fully loaded
4. Open a command prompt on the PC (cmd.exe), type and confirm each command with ENTER:
5. cd /d c:mini-sdk
6. adb shell
7. su
8. restorecon -FR /data/media/0
9. exit

Whats going to happen? Restorecon is a program used to restore file(s) default SELinux security contexts. It can be run at any time to correct errors or to add support for new policy. With a corrected SELinux security context for the /data/media/0 you will be able to access the content of the virtual SD card again.

Do you have any questions or comments? Feel free to share! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) below this post!

For latest news follow Android Revolution HD on popular social platforms:

Read More..

How to Use adb sideload on your Android device

Probably every Android power-user at least once in his life used ADB - Android Debug Bridge. It is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. Using ADB shell commands gives you additional control over your device and sometimes it can save your device from being bricked (example: How to: copy ROM zip file to the freshly wiped device). You can find some more basic information about ADB here.

Since Android Jelly Bean there has been a new ADB mode available in the AOSP recovery, incorporated by the Android developer community into custom recoveries too. It is called "ADB sideload" and most of you probably have heard about it already. This is an alternate method to the one I wrote about here - How to: copy ROM zip file to the freshly wiped device. The main difference is that ADB sideload works only with recoveries based on Jelly Bean source or newer. I believe that ADB sideload was created to simplify the process of flashing/restoring Android update.zip packages.

Keep in mind that while using ADB sideload, the regular ADB shell wont work. To be able to use SIDELOAD mode make sure youre running latest ADB drivers from the Android SDK (Platform-tools). Here are the simple steps you need to follow to flash update.zip package using adb sideload mode (based on stock Android recovery):

1. Place the ZIP package you want to install in the same location where you keep ADB drivers - adb.exe, AdbWinApi.dll and AdbWinUsbApi.dll (usually its SDKplatform-tools)
2. Make sure you have USB debugging enabled in Settings > Development on your device
3. Make sure your phone drivers are installed on the PC youre going to use
4. Boot your device in recovery mode (Android logo with a exclamation mark) and connect your device to PC
5. Hold down "power" button first, followed quickly by "volume up" button. You should now see the recovery menu
6. Use the volume up/down keys to select "apply update from ADB," then press power to select it
7. Open a command prompt on the PC (cmd.exe), type and confirm with ENTER:
8. cd /d <adb.exe location> (for example: cd /d c:SDKplatform-tools) or you can open your SDK/platform-tools folder, then press SHIFT button and the right-click mouse button and choose “Open command prompt here”
9. adb sideload <filename>.zip (for example: adb sideload update.zip)
10. The zip package will begin installing. When its done, select "reboot system now."

How is that different from the alternative method? You dont have to manually create the proper folders structure, push the file and later install if from inside the recovery menu. The result is basically the same, because ADB sideload is also transferring the zip file into the device internal memory and later it automatically begins the installation procedure. However, it works only with recoveries based on Android Jelly Bean source.

Have any questions or comments? Feel free to share! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) below this post!

Read More..