Iubris

May 28, 2013

android emulator x86 with google maps apis

Ok, this night's question is:
can we definitely have an android emulator image using x86 cpu (to exploit kvm acceleration) and google maps support?
The answer is: yes.
But, as always, we could have less pain banging our head against the wall.

However, here the tricks.

Create two avd image, an *arm* ones and an *intel* ones, from shell or using eclipse tools, and assume their names are "ga17_tablet10_arm" and "ga17_tablet10_intel"
- ga = "google apis"
- 17 = android selected version
- tablet10 = a 10'' 1280x800 tablet
- arm/intel = obviously, isn't?)
(If *avd" image is already present, skip first creation)
```
export ARM_NAME="ga17_tablet10_arm"
export INTEL_NAME="ga17_tablet10_intel"
```
or choose different names
Then we have to copy some files from arm instance.
So, start the avd image and do the stuff [emulator -avd "$ARM_NAME" &]
Assuming we're working in a dir with enough space (we need about 350mb), we must have a tree as:
```
[k0smik0@n-johnny-5-iii from_ga17_arm]$ find system/ -type d
system/
system/app
system/etc
system/etc/permissions
system/framework
```
so
```
mkdir -p system/app system/etc/permissions system/framework
```

Now we have to pull down these files (change ARM_EMU_ID with yours, grabbing it from "adb devices"):

export ARM_EMU_ID=emulator-5554;
adb -s $ARM_EMU_ID pull /system/etc/permissions/com.google.android.maps.xml system/etc/permissions
adb -s $ARM_EMU_ID pull /system/framework/com.google.android.maps.jar system/framework
adb -s $ARM_EMU_ID pull /system/app/FusedLocation.apk system/app
adb -s $ARM_EMU_ID pull /system/app/GoogleLoginService.apk system/app
adb -s $ARM_EMU_ID pull /system/app/GoogleServicesFramework.apk system/app
adb -s $ARM_EMU_ID pull /system/app/GpsLocationTest.apk system/app
adb -s $ARM_EMU_ID pull /system/app/Maps.apk system/app
adb -s $ARM_EMU_ID pull /system/app/NetworkLocation.apk system/app

Then, we have to push these files in *x86/intel* avd image, in same directories:
assuming:

you're using a 64 linux with kvm acceleration (hence "emulator64-x86")
"$INTEL_NAME" is env variable for intel avd image name (see 1, above)
300 (mb) is enough space you need - and it must be greater than what you have specified on image creation (item 1) [default is 260mb]

achtung! you have to change data partition size before you start emulator, because new system image will be saved in /data; as you can see u have to increase it:

grep -ni dataPartition\.size ~/.android/avd/"$INTEL_NAME".avd/*ini
config.ini:3:disk.dataPartition.size=200M
hardware-qemu.ini:40:disk.dataPartition.size = 200m

so change these values in config.ini and hardware-qemu.ini [vim?ed?sed?] from 200M to 400M (or higher, depends how you want expand /system). and now:

emulator64-x86 -partition-size 300 -netspeed full -netdelay none -no-boot-anim -no-audio -gpu on -avd $INTEL_NAME -qemu -enable-kvm &
export INTEL_EMU_ID=emulator-5556; # replace with yours
sleep 10; # adb connection takes some seconds
adb remount
adb -s $INTEL_EMU_ID push system/etc/permissions/com.google.android.maps.xml /system/etc/permissions/
adb -s $INTEL_EMU_ID push system/framework/com.google.android.maps.jar /system/framework/
for i in system/app/*; do adb -s $INTEL_EMU_ID push $i /system/app ; done

Is it enough? No, obviously. These new changes don't remain after avd instance reboot, therefore we have to save /system partition.
So, save this mkfs.yaffs2.x86 and push it to the device:
```
wget https://android-group-korea.googlecode.com/files/mkfs.yaffs2.x86
adb -s $INTEL_EMU_ID push mkfs.yaffs2.x86 /data
```
create a new system image from existing ones:
```
adb -s $INTEL_EMU_ID shell chmod 755 /data/mkfs.yaffs2.x86
adb -s $INTEL_EMU_ID shell /data/mkfs.yaffs2.x86 /system /data/system.img
```
and now save new image (this could take a while, so get a beer):
```
adb -s $INTEL_EMU_ID pull /data/system.img
```
just for info: mine reports "829 KB/s (304309632 bytes [~291mb] in 358.296s [~6s])"
1. local/specific instance
  
  copy system.img in avd directory:
```
cp -a system.img ~/.android/avd/"$INTEL_NAME".avd/
```
2. global method
  
  copy this new system.img in $ANDROID_SDK/add-ons/addon-google_apis-google-$SELECTED_WORKING_VERSION/images/x86 - assuming that:
  - ANDROID_SDK is your android directory installation
  - SELECTED_WORKING_VERSION is android release you have choice when you created avd images (I used jellybean_mr1 = 17 -- see item 1)
  and copy other files from x86 (without maps support) sdk dir, that is:
```
export ANDROID_SDK=/your/android/installation/dir;
export SELECTED_WORKING_VERSION=17;
cp -a $ANDROID_SDK/system-images/android-$SELECTED_WORKING_VERSION/x86/* $ANDROID_SDK/add-ons/addon-google_apis-google-$SELECTED_WORKING_VERSION/images/x86
cp -f system.img $ANDROID_SDK/add-ons/addon-google_apis-google-$SELECTED_WORKING_VERSION/images/x86
```

and finally kill emulators

adb -s $INTEL_EMU_ID emu kill
adb -s $ARM_EMU_ID emu kill

enjoy this new one intel emulator with google maps ;D

credits to: http://codebutler.com/2012/10/10/configuring-a-usable-android-emulator/

June 24, 2012

Android Compatibility Package and GoogleMaps issues: FragmentMapActivity and MapFragment

Chapter 1: "The Good, The Bad and The Ugly"

A short introduction:

The target - the cemetery treasure:

we want develop an android app for all platforms, from 1.6 to 4.x, having same ui and backend code. i.e., we want write once, and run everywhere.
(Did you know those words, isn't ?)

The requirements - we have to make an alliance with "The Ugly"

So, we have (only?) to use fragment support from compatibility package, in order to take advantage of fragments paradigma in our application, on device which version < 3.x - honeycomb.
Easy, isn't ? Not so much.

The problem - aka "The Bad"

Android compatibility package doesn't offer support for maps in fragments, so there is not mapfragment for us.
Then, we could just implement our own version... just a "MapFragment extends Fragment"; and honoring fragments paradigma, we let fragment contains all ui/event code.
And an obvious thing is to be able to instance MapView in our MapFragment.

But immediately the first problem: we know a *Fragment must be attached to *FragmentActivity, and we know a MapView must living in a MapActivity - and we don't have a MapActivity with fragment support. There is nothing about this in compatibility package.
The unique existing FragmentActivity inherits from Activity, so the problem.

The road to solution, "The Good"

Pete Doyle proposes first solution, modifiyng the compatibility package source, and we can have a FragmentActivity inheriting from MapActivity.
You can see all about it on his github https://github.com/petedoyle/android-support-v4-googlemaps.
However, the problem is that only one MapActivity is supported per process (here details)
Taro Kobayashi talks about this in his blog http://uwvm.blogspot.jp
So, two alternatives:

we have only and only one FragmentActivity inheriting from MapActivity in our app, and we have to project ui as a "detach current fragment" then "attach next fragment" ("replace" method has some issues in fragment support)
have a distinct FragmentMapActivity inheriting from MapActivity, and obviously providing fragment support while honors compatibility package.
reading in Kobayashi blog, it's evident he prefers this second way.. et voila his fork from petedoyle's project:
https://github.com/9re/android-support-v4-googlemaps

And yes, I also searched a solution for all this issue, and even providing the second way too.
Searched, tried to implement my ones, and so on. As long as i just found Kobayashi ones ;D So, it just remains to use ? Oh no, nothing is as easy as it sounds.

"Hey Blondie! You know what you are? Just a dirty son of a ahAHahAHaaaaah!"

As already shown in petedoyle's project, there is some issue with MapFragment, especially instancing MapView:
https://github.com/petedoyle/android-support-v4-googlemaps/blob/master/samples/FragmentLayoutMaps/src/com/example/android/apis/app/FragmentLayout.java plz focus on "onCreateView", row 224 (and row 80, for fields declarations)

As you could see, Pete instances a View inflating from R.layout.map, that is file containing <com.google.android.maps.MapView> (or another MapView), and then this view is returned as viewcontainer in onCreateView.
In onCreateView body he use mapview and does his stuffs, and you can see as View mapView and View mapViewContainer are instanced in parent FragmentMapActivity. But why ?

Fragment borns to contains all ui and event code, and handles fields life within its lifecycle, so we would instance our fields in our MapFragment, not in FragmentMapActivity.

Then, my endeavour (anyhow, it works) for MapFragment:

it handles viewContainer directly, instancing it in onAttach;
it is an abstract class, with "providesMapViewContainerId" abstract method;
in concrete subclass, it provides file layout resource id
a concrete (final?) "addMapViewToViewParent" method, to be invoked within concrete subclass onCreateView, passing View parameter as its first parameter, and our MapView as second ones.

And MapView where it comes from?
Simply with findViewById (or injecting as singleton, if you use roboguice). So:

public MyMapFragment extends MapFragment {
   private MapView mapView;
   /*
    * other methods
    */
   @Override
   public void onViewCreated(View view, Bundle savedInstanceState) {
      super.onViewCreated(view, savedInstanceState);
      if (mapView == null) // cause only mapview is admitted
         mapView = getActivity().findViewById(R.id.yourmapview);
      addMapViewToViewParent(view,mapView);

      // your stuffs with mapview
   }
}

and MapFragment.java on github or code below:

/*
 * Copyright (C) 2012 Massimiliano Leone - maximilianus@gmail.com
 * Licensed under the Apache License, Version 2.0 (the "License");
 */
package android.support.v4.app;

import android.app.Activity;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.FrameLayout;

import com.google.android.maps.MapView;

public abstract class MapFragment extends Fragment {

  private View mapViewContainer;

  /**
    * inflating from layout provided by (your concrete) providesMapViewContainerId method;
    * here we instance the viewcontainer returned by onViewCreated,
    * something as:
    *
    * <pre>return LayoutInflater.from(activity).inflate(R.layout.yourmaplayout, null);* </pre>
    */
  @Override
  public void onAttach(Activity activity) {
    super.onAttach(activity);       

    if (mapViewContainer == null) {
      mapViewContainer =  LayoutInflater.from(activity).inflate( providesMapViewContainerId(), null);
    }
  }

  /**
    * in your concrete class you have to provide the layout containing mapview:
    * something as:
    *
    * "return R.layout.map;"
    * where R.layout.map is map.xml file in layout directory, declaring a RelativeLayout,
    * which contains Mapview, as below:
    *
    * <pre>
    *  <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    *   android:id="@+id/maplayout"
    *   android:orientation="vertical"
    *   android:layout_width="fill_parent"
    *   android:layout_height="fill_parent">

    *  <com.google.android.maps.MapView
    *    android:id="@+id/mapview"
    *    android:layout_width="fill_parent"
    *    android:layout_height="fill_parent"
    *    android:clickable="true"
    *    android:apiKey="YOUR_APIKEY"/>
    *  </RelativeLayout>
    * </pre>    
    * @param activity
    * @return View
    */
  protected abstract int providesMapViewContainerId();

  protected void addMapViewToViewParent(View view, MapView mapView) {

    ViewGroup viewGroup = (ViewGroup) view.getParent();
    if (viewGroup == null) viewGroup = (ViewGroup) view;
    int childs = viewGroup.getChildCount();
    if (childs == 0) {
 viewGroup.addView(mapView);
    } else {
 for (int i = 0; i < viewGroup.getChildCount(); i++) {
   View child = viewGroup.getChildAt(i);
   if (child instanceof FrameLayout) {
       continue;
   } else if (child instanceof MapView) {
       viewGroup.removeView(child);
       viewGroup.addView(mapView, 1);
   } else {
       viewGroup.removeView(child);
   }
      }
      //viewGroup.addView(mapView, 0);
    }
    viewGroup.invalidate();
  }   

  @Override
  public View onCreateView(LayoutInflater inflater, ViewGroup container,Bundle savedInstanceState) {
  return mapViewContainer;
  }

  @Override
  public void onDestroyView() {
    super.onDestroyView();
    ViewGroup parentViewGroup = (ViewGroup) mapViewContainer.getParent();
    if( parentViewGroup != null ) {
      parentViewGroup.removeView( mapViewContainer );
      //parentViewGroup.removeAllViews();
    }
  }   

}

March 6, 2012

some android ui tools and tutorial

http://android-ui-utils.googlecode.com/hg/asset-studio/dist/icons-actionbar.html#source.space.trim=1&source.space.pad=0&name=sort&theme=light

http://blogfreakz.com/mobile-development/android-gui-icons-and-fonts/

http://developer.android.com/design/style/color.html

http://developer.android.com/guide/practices/ui_guidelines/index.html

March 1, 2012

nice presentation about roboguice

http://www.blog.project13.pl/wp-content/uploads/2011/12/presentation.html#slide1

February 17, 2012

Android - Creating custom button assets

Android Developers — Visual Design Screencast — Creating custom button assets - YouTube:

for creating android button

January 7, 2012

android usb reverse tethering via code

welcome again !

the problem of day is:
when i enable usb reverse tethering adb doesn't not respond anymore, via usb.

so, to have all working (reverse tethering, adb, etc) we need many operations:
1) enable reverse tethering via settings
2) change adb prop to enable tcp
3) start a dhcp request on usb0
4) disable wifi
5) other annoying stuffs?

(and reverse, of course :/)

so, it's time to find an -ultimate- solution.

1) with LLAMA (don't u know LLAMA? know it ! https://market.android.com/details?id=com.kebab.Llama ) i can start a "enable reverse tethering and so others stuff" when i plug the cable (and when certain others conditions are verified - for example: i was in wifi, so i want again connectivity).

2) with irssi connectbot (https://play.google.com/store/apps/details?id=org.woltage.irssiconnectbot) i can start some script which call dhcpd and change adb prop (just a "adb_tcp" script to enable adb over tcp, and "adb_usb" to rechange over usb)

download https://raw.github.com/k0smik0/burt/master/scripts/adb_tcp

#!/system/bin/sh

setprop service.adb.tcp.port 5555
stop adbd
start adbd

and download https://raw.github.com/k0smik0/burt/master/scripts/adb_usb

#!/system/bin/sh

setprop service.adb.tcp.port -1
stop adbd
start adbd

and "netcfg usb0 dhcp" to start a dhcp request (plz attention you need ROOTED phone in order to execute this last one - in general, a rooted phone is needed for all the tricks, actually...)

3) last thing (but it's the worst problem) is to enable usb tethering, and i don't want to check via settings, so it's time to code some lines.

the idea beyond is just simple:
send a broadcast message and a receiver intercepts it and enables/disables usb tethering.
Below, the receiver:

/**
 * GPL Copyleft 2012 Massimiliano Leone - maximilianus@gmail.com .
 */
package net.iubris.burt;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;

public class UsbReverseTetheringIncomingReceiver extends BroadcastReceiver {

  protected static final String ACTION_START = "net.iubris.burt.START";
  protected static final String ACTION_STOP = "net.iubris.burt.STOP";
 
  @Override
  public void onReceive(Context context, Intent intent) {
    final String action = intent.getAction();  
    final Object obj = context.getSystemService(Context.CONNECTIVITY_SERVICE);
    if (action.equals(ACTION_START)) {
      actOnTether(obj, "tether");
    } else if (action.equals(ACTION_STOP)) {
      actOnTether(obj, "untether");
    }
  }
    
  private final void actOnTether(Object obj, String act) {
    for (Method m : obj.getClass().getDeclaredMethods()) {
      if (m.getName().equals(act)) {
 try {
   m.invoke(obj, "usb0");
 } catch (IllegalArgumentException e) {
   e.printStackTrace();
 } catch (IllegalAccessException e) {
   e.printStackTrace();
 } catch (InvocationTargetException e) {
   e.printStackTrace();
 }
      }
    }
  } 
}

and the relative AndroidManifest.xml with receiver declaration, permissions, etc.

<manifest android:versioncode="1" android:versionname="1.0" package="net.iubris.burt" xmlns:android="http://schemas.android.com/apk/res/android">

  <uses-sdk android:minsdkversion="8">
    
  <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE">
  <uses-permission android:name="android.permission.CHANGE_NETWORK_STATE">

  <application android:debuggable="false" android:icon="@drawable/icon" android:label="@string/app_name">
    <activity android:label="@string/app_name" android:name=".UsbReverseTetheringActivity">
      <intent-filter>
 <action android:name="android.intent.action.MAIN">
   <category android:name="android.intent.category.LAUNCHER"/>
 </action>
      </intent-filter>
    </activity>
    <receiver android:enabled="true" android:name=".UsbReverseTetheringIncomingReceiver">
      <intent-filter>
 <action android:name="net.iubris.burt.START"/>
 <action android:name="net.iubris.burt.STOP"/>
      </intent-filter>
    </receiver>
  </application>
</manifest>

ok, there is also an activity, with 2 buttons start/stop.. but just for a visual sample:
actually, into code, the buttons send broadcast "net.iubris.burt.START" and "net.iubris.burt.STOP"

so, in terminal (irssi connectbot? another else?) the commands are just:

am broadcast -a "net.iubris.burt.START" # to enable
am broadcast -a "net.iubris.burt.STOP" # to disable

and obviously via adb: "adb shell am broadcast etc."

4) finally, a summa cum laude of all these pieces :
--- open irssi connectbot ---
- create a "local" connection called "start usb reverse tethering" (or as u prefer)
- edit its "post-login automation" with these lines (careful to return or use && !)

am broadcast -a net.iubris.burt.START
su -c "netcfg usb0 dhcp"
su -c "adb_tcp"

adb_tcp (from 1, above) is just a script, so u can replace last line with:

su -c "setprop service.adb.tcp.port 5555 && stop adbd && start adbd"

in some terminals (due to kernel/rom version) this last ones is not needed, because adb over usb is working also with usb reverse tethering

--- open Llama ---
- create new event and call "start usb reverse tethering" (or as u want)
- add condition "charging status" as "charging from usb" and other conditions u want it matches (i.e. i have "wifi network connected" = "on" so this switch from wifi to usb r.t. does its jobs because phone is really in a state which we can call "connected")
- add actions: "toggle wifi" as "wifi off" and "run app shortcut" as [irssiconnectbot action], that is the irssiconnectbot local connection u specified above, "start usb reverse tethering" (or name you used for)

5) and to restore ?
--- for irssi-connectbot, a new local connection called "stop usb reverse tethering", where "post-login automation" is:

am broadcast -a net.iubris.burt.STOP
su -c "adb_usb"
as for "adb_tcp", the "adb_usb" is just these commands:
su -c "setprop service.adb.tcp.port -1 && stop adbd && start adbd"

--- and in LLama, an event for "stop usb reverse tethering" can be something like where match condition "charging status" = "using battery" and action "run app shortcut" is irssi-connectbot "stop usb reverse tethering"

finally, the "burt" receiver project on github burt and the builder apk burt.apk

credits to:
http://tjandroid.blogspot.com/2010/12/enabledisable-usb-tethering.html
http://www.apad.tv/apadforum/showthread.php?1280-Solved-system-bin-sh-am-not-found-and-system-bin-sh-pm-not-found