Linux.com

Community Blogs



Mobile Phone Management Made Easy

Mobile phone users should not regard their computer only as the means of recharging their phone, or transferring files to and from the phone's storage. There's a lot more than you can do with your Linux box. This article illustrates some good open source tools that let you manage your mobile phone.

This roundup selects 4 of my favourite mobile phone management tools; all of them are released under an open source license.

<A HREF="http://www.linuxlinks.com/article/20140705063155544/MobilePhoneManagement.html">Read on</A>

 

Mobile Development: How to Install Android Studio on Ubuntu Version 14.04

This article is focused towards Android App Development in a Linux distribution, especially in Ubuntu 14.04 environment using the Android Studio.

Android Studio, is an IntelliJ IDEA-based Android development environment, which is currently in the Beta stage. It is packed with multi-features and improvements over Eclipse ADT. As currently it is in beta stage, once it reaches to the final stage of development, it will be known as Android IDE. It provides a comprehensive tool for developing and debugging applications for the Google operating system for mobile devices. With the help of IntelliJ, the Android Studio offers the following features:

  • Flexible Gradle-based build system.
  • Ability to generate and build multiple APK & variants, respectively.
  • Extended template support for Google-based services and several types of devices.
  • Theme editing support with rich layout editor.
  • Catch the performance, usability, version compatibility, and other problems with the Lint tools.
  • Fully capable of ProGuard and app-signing.
  • Easily integrate Google Cloud Messaging and App Engine with its built-in support for Google Cloud Platform.

Download the Android Studio from here.
This download includes:

  • Android Studio Beta.
  • All the Android SDK Tools to design, test, and debug your app.
  • A version of the Android platform to compile your app.
  • A version of the Android system image to run your app in the emulator.

The following procedure is for installing Android Studio, and therefore does not serve to update it. That's because the program has its own "Update Manager". With this update to Android Studio to the latest version, just click "Check for updates now" in the welcome screen, and simply click "Update and Restart":

Update Android Studio

Please remember that, the package will try to install one of these JDKs: default-jdk, oracle-java7-installer or oracle-java8-installer. So, just make sure that, installing the Android Studio, install one of these packages via the PPA repository.

How to Install Android Studio on Ubuntu Studio 14.04?

In order to install Android Studio on Ubuntu Studio 14.04 and derivatives, do the following:

Step 1: Open a terminal using the Dash or pressing Ctrl + Alt + T keys.
Step 2: If you have not, add that repository with the following command:

sudo add-apt-repository ppa: paolorotolo / android-studio

Step 3: Update the APT with the command:

sudo apt-get update

Step 4: Now install the program with the command:

sudo apt-get install android-studio

Step 5: Once installed, run the program by typing in Dash:

studio

 

Android Asynctask Internal - Half Sync Half Async Design Pattern

The way Asynctask has been implemented in Android, is an apt example of Half Sync - Half Async pattern described in Pattern Oriented Software Architecture or POSA2. First of all, let us try to understand what we mean by Half Sync-Half Async design pattern. Half Sync- Half Async pattern is a specific way how we want to structure our threads in a multithreaded application. As the name suggests, in this pattern we divide the solution of managing multiple threads into two different specific zones - one is synchronous and the other is an asynchronous zone. The main thread communicates with a thread asynchronously and this thread is responsible for queuing multiple tasks in a FIFO order. This thread then pushes these tasks on the synchronous layer to different threads taken from a thread pool. These thread pools then execute these tasks synchronously in the background. The whole process can be depicted by the following diagram.



If you are new to the terms Asynchronous and Synchronous in the conjunction of multithreaded application let me throw some lights on it. These can be best understood in a client-server architecture perspective. A synchronous function means it will block the caller of it and will return only after it finishes its task. On the other hand an asynchronous function starts its task in the background but returns immediately to the caller. When it finishes the background task, it notifies the caller about it asynchronously and then the caller takes action.


The two scenarios have been depicted by the following two diagrams.



Now let us dive deep into the Android’s Asynctask.java file to understand it from a designer’s perspective and how it has nicely implemented Half Sync-Half Async design pattern in it.


In the beginning of the class few lines of codes are as follows:


private static final ThreadFactory sThreadFactory = new ThreadFactory() {

       private final AtomicInteger mCount = new AtomicInteger(1);


       public Thread newThread(Runnable r) {

           return new Thread(r, "AsyncTask #" + mCount.getAndIncrement());

       }

   };


   private static final BlockingQueue<Runnable> sPoolWorkQueue =

           new LinkedBlockingQueue<Runnable>(10);


   /**

   * An {@link Executor} that can be used to execute tasks in parallel.

   */

   public static final Executor THREAD_POOL_EXECUTOR

           = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,

                   TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);

The first is a ThreadFactory which is responsible for creating worker threads. The member variable of this class is the number of threads created so far. The moment it creates a worker thread, this number gets increased by 1.


The next is the BlockingQueue. As you know from the Java blockingqueue documentation, it actually provides a thread safe synchronized queue implementing FIFO logic.


The next is a thread pool executor which is responsible for creating a pool of worker threads which can be taken as and when needed to execute different tasks.


If we look at the first few lines we will know that Android has limited the maximum number of threads to be 128 (as evident from private static final int MAXIMUM_POOL_SIZE = 128).


Now the next important class is SerialExecutor which has been defined as follows:


private static class SerialExecutor implements Executor {

       final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();

       Runnable mActive;


       public synchronized void execute(final Runnable r) {

           mTasks.offer(new Runnable() {

               public void run() {

                   try {

                       r.run();

                   } finally {

                       scheduleNext();

                   }

               }

           });

           if (mActive == null) {

               scheduleNext();

           }

       }


       protected synchronized void scheduleNext() {

           if ((mActive = mTasks.poll()) != null) {

               THREAD_POOL_EXECUTOR.execute(mActive);

           }

       }

   }

The next important two functions in the Asynctask is

public final AsyncTask<Params, Progress, Result> execute(Params... params) {

       return executeOnExecutor(sDefaultExecutor, params);

   }


and


public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec,

           Params... params) {

       if (mStatus != Status.PENDING) {

           switch (mStatus) {

               case RUNNING:

                   throw new IllegalStateException("Cannot execute task:"

                           + " the task is already running.");

               case FINISHED:

                   throw new IllegalStateException("Cannot execute task:"

                           + " the task has already been executed "

                           + "(a task can be executed only once)");

           }

       }


       mStatus = Status.RUNNING;


       onPreExecute();


       mWorker.mParams = params;

       exec.execute(mFuture);


       return this;

   }


AS it becomes clear from the above code we can call the executeOnExecutor from exec function of Asynctask and in that case it takes a default executor. If we dig into the sourcecode of Asynctask, we will find that this default executor is nothing but a serial executor, the code of which has been given above.


Now lets delve into the SerialExecutor class. In this class we have final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();.


This actually works as a serializer of the different requests at different threads. This is an example of Half Sync Half Async pattern. it actually puts a task in the end of the mTasks arraydeque and then pushes them to different threads from the threadpool. Look at the code


public void run() {

                   try {

                       r.run();

                   } finally {

                       scheduleNext();

                   }

what it actually does it runs in an endless loop waiting for new tasks to arrive and whenever a new task arrives it calls scheculeNext() which actually runs this task in a thread from the threadpool. However, it allows only one task to be executed at any time. Hence with the default executor we cannot have multiple tasks executing parallelly.


Now lets examine how the serial executor does this. Please have a look at the portion of the code of the SerialExecutor which is written as



if (mActive == null) {

            scheduleNext();


           }

So when the execute is first called on the Asynctask, this code is executed on the main thread (as mActive will be initialized to NULL) and hence it will take us to the scheduleNext() function.

The ScheduleNext() function has been written as follows:

 protected synchronized void scheduleNext() {

           if ((mActive = mTasks.poll()) != null) {

               THREAD_POOL_EXECUTOR.execute(mActive);

           }

       }


In this function we initialize the mActive by the Runnable object of the AraayDeque which is already inserted in that Queue. The the task will be executed in a thread taken from the threadpool. While executing this task in a thread from the threadpool, the finally portion of the run method becomes responsible for calling the Schedulenext() function which polls the queue (nonblocking) and whenever there is a new task it executes that in a thread taken from the threadpool.


To understand why the execute function cannot be called more than once on the same Asynctask, please have a look at the below code snippet taken from ExecutoronExecute function of Asynctask.java especially in the below mentioned portion:


 if (mStatus != Status.PENDING) {

           switch (mStatus) {

               case RUNNING:

                   throw new IllegalStateException("Cannot execute task:"

                           + " the task is already running.");

               case FINISHED:

                   throw new IllegalStateException("Cannot execute task:"

                           + " the task has already been executed "

                           + "(a task can be executed only once)");

           }

       }

AS from the above code snippet it becomes clear that if we call execute function twice when a task is in the running status it throws an IllegalStateException saying “Cannot execute task: the task is already running.”.


if we want multiple tasks to be executed parallely, we need to call the execOnExecutor passing Asynctask.THREAD_POOL_EXECUTOR (or maybe an user defined THREAD_POOL as the exec parameter. And if we do that, the sPoolWorkQueue becomes responsible for the Half Sync Half Async pattern for Asynctask.

 

Dissection of Android Services Internals

Have you ever wondered how an app gets an handle to the system services like POWER MANAGER or ACTIVITY MANAGER or LOCATION MANAGER and several others like these. To know that i dug into the source code of Android and found out how this is done internally.

So let me start from the application side’s java code.


At the application side we have to call the function getService and pass the ID of the system service (say POWER_SERVCE) to get an handle to the service.


Here is the code for getService defined in  /frameworks/base/core/java/android/os/ServiceManager.java


/**
44     * Returns a reference to a service with the given name.
45     *
46     * @param name the name of the service to get
47     * @return a reference to the service, or <code>null</code> if the service doesn't exist
48     */
49    public static IBinder getService(String name) {
50        try {
51            IBinder service = sCache.get(name);
52            if (service != null) {
53                return service;
54            } else {
55                return getIServiceManager().getService(name);
56            }
57        } catch (RemoteException e) {
58            Log.e(TAG, "error in getService", e);
59        }
60        return null;
61    }


Suppose we don’t have the service in the cache. Hence we need to concentrate on the line 55

return getIServiceManager().getService(name);


This call actually gets an handle to the service manager and asks it to return a reference of the service whose name we have passed as a parameter.



Now let us see how the getIServiceManager() function returns a handle to the ServiceManager.


Here is the code of getIserviceManager() from /frameworks/base/core/java/android/os/ServiceManager.java


private static IServiceManager getIServiceManager() {
34        if (sServiceManager != null) {
35            return sServiceManager;
36        }
37
38        // Find the service manager
39        sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
40        return sServiceManager;
41    }


The ServicemanagerNative.asInterface() looks like the following:


/**
28     * Cast a Binder object into a service manager interface, generating
29     * a proxy if needed.
30     */
31    static public IServiceManager asInterface(IBinder obj)
32    {
33        if (obj == null) {
34            return null;
35        }
36        IServiceManager in =
37            (IServiceManager)obj.queryLocalInterface(descriptor);
38        if (in != null) {
39            return in;
40        }
41
42        return new ServiceManagerProxy(obj);
43    }



So basically we are getting an handle to the native servicemanager.


This asInterface function is actually buried inside the two macros DECLARE_META_INTERFACE(ServiceManager) and IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");

defined in IserviceManager.h and IServiceManager.cpp respectively.


Lets delve into the two macros defined in /frameworks/base/include/binder/IInterface.h


DECLARE_META_INTERFACE(ServiceManager) macro.


Its defined as


// ----------------------------------------------------------------------
73
74#define DECLARE_META_INTERFACE(INTERFACE)                               \
75    static const android::String16 descriptor;                          \
76    static android::sp<I##INTERFACE> asInterface(                       \
77            const android::sp<android::IBinder>& obj);                  \
78    virtual const android::String16& getInterfaceDescriptor() const;    \
79    I##INTERFACE();                                                     \
80    virtual ~I##INTERFACE();                                            \

And the IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");

has been defined as follows:


#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME)                       \
84    const android::String16 I##INTERFACE::descriptor(NAME);             \
85    const android::String16&                                            \
86            I##INTERFACE::getInterfaceDescriptor() const {              \
87        return I##INTERFACE::descriptor;                                \
88    }                                                                   \
89    android::sp<I##INTERFACE> I##INTERFACE::asInterface(                \
90            const android::sp<android::IBinder>& obj)                   \
91    {                                                                   \
92        android::sp<I##INTERFACE> intr;                                 \
93        if (obj != NULL) {                                              \
94            intr = static_cast<I##INTERFACE*>(                          \
95                obj->queryLocalInterface(                               \
96                        I##INTERFACE::descriptor).get());               \
97            if (intr == NULL) {                                         \
98                intr = new Bp##INTERFACE(obj);                          \
99            }                                                           \
100        }                                                               \
101        return intr;                                                    \
102    }                                                                   \
103    I##INTERFACE::I##INTERFACE() { }                                    \
104    I##INTERFACE::~I##INTERFACE() { }  


So if we replace expand these two macros in IServiceManager.h & IServiceManager.cpp file with the appropriate replacement parameters they look like the following:



  1. class IServiceManager : public IInterface
    {
    public:
      
    static const android::String16 descriptor;  

  2.    static android::sp<IServiceManager> asInterface( const android::sp<android::IBinder>& obj);  

  3.    virtual const android::String16& getInterfaceDescriptor() const;

  4.    IServicemanager();  

  5.    virtual ~IServiceManager();  

…......

….....

…...

…..


And in
IServiceManager.cpp


  1.  

  2.    const android::String16 IServiceManager::descriptor("android.os.IServiceManager”);             

  3.    const android::String16&  

  4.           IServiceManager::getInterfaceDescriptor() const {  

  5.        return  IServiceManager::descriptor;

  6.    }    

  7.    android::sp<IServiceManager> IServiceManager::asInterface(   

  8.            const android::sp<android::IBinder>& obj)  

  9.    {   

  10.        android::sp< IServiceManager> intr;    

  11.        if (obj != NULL) {     

  12.            intr = static_cast<IServiceManager*>(   

  13.                obj->queryLocalInterface(  

  14.                        IServiceManager::descriptor).get());    

  15.            if (intr == NULL) {   

  16.                intr = new BpServiceManager(obj);  

  17.            }  

  18.        }     

  19.        return intr;    

  20.    }     

  21.    IServiceManager::IServiceManager() { }    

  22.    IServiceManager::~IIServiceManager { }      


So if you see the line 12 which shows if the Service Manager is up and running (and it should because the service manager starts in the init process during Android boot up) it returns the reference to it through the queryLocalinterface function and it goes up all the way to the java interface.


now once we get the reference of the Service Manager, we next call


public IBinder getService(String name) throws RemoteException {
116        Parcel data = Parcel.obtain();
117        Parcel reply = Parcel.obtain();
118        data.writeInterfaceToken(IServiceManager.descriptor);
119        data.writeString(name);
120        mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
121        IBinder binder = reply.readStrongBinder();
122        reply.recycle();
123        data.recycle();
124        return binder;
125    }



from  ServiceManagerNative.java. in this function we pass the service that we are looking for.


And the onTransact function for GET_SERVICE_TRANSACTION on the remote stub looks like the following:


public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
51    {
52        try {
53            switch (code) {
54            case IServiceManager.GET_SERVICE_TRANSACTION: {
55                data.enforceInterface(IServiceManager.descriptor);
56                String name = data.readString();
57                IBinder service = getService(name);
58                reply.writeStrongBinder(service);
59                return true;
60            }
61
62            case IServiceManager.CHECK_SERVICE_TRANSACTION: {
63                data.enforceInterface(IServiceManager.descriptor);
64                String name = data.readString();
65                IBinder service = checkService(name);
66                reply.writeStrongBinder(service);
67                return true;
68            }
69

//Rest has been discarded for brevity…………………..


………………….

………………….

…………………



It returns the reference to the needed service through the function getService.






/////////////////////////////////////

The getService function from /frameworks/base/libs/binder/IServiceManager.cpp

looks like the following:


 virtual sp<IBinder> getService(const String16& name) const
134    {
135        unsigned n;
136        for (n = 0; n < 5; n++){
137            sp<IBinder> svc = checkService(name);
138            if (svc != NULL) return svc;
139            LOGI("Waiting for service %s...\n", String8(name).string());
140            sleep(1);
141        }
142        return NULL;
143    }

So it actually checks if the Service is available and then returns a reference to it. Here i would like to add that when we return a reference to an IBinder object, unlike other data types it does not get copied in the client’s address space, but its actually the same reference of the IBinder object which is shared to the client through a special technique called object mapping in the Binder driver.

 

Witech Presenting ALL-READY Linux&Android Development Kit

The well-known ARM development kit supplier Witech Embedded recently introduced another high-end ARM Cortext-A8 Linux&Android dev kit based on Samsung S5PV210 microcontroller targeting multi-media terminal, consumer electronic devices and invehicle infotainment systems, with the name of OK210-A.

ok210 7

Just like the elder OK6410, OK210-A is also designed to be ALL-READY. “By ALL-READY we mean the OK210-A is delivered with everything ready-to-go. The OK210-A carries almost everything that customers would need, and everything is already working”, says the CEO of Witech Embedded, “Together with the OK210-A we provide board support packages for Embedded Linux and Android, the most popular embedded operating systems in the current world, which includes complete drivers and sample programs for all on-board resources. Customers can either use them directly, or customize their own systems on the basis of provided resources”.

“Purpose of introducing such all-ready products is to help customers to simplify their development cycle, shorten time-to-market and avoid design risks”, said the CEO.

ok210_itf

The OK210-A features:
• Samsung S5PV210 ARM Cortex-A8 microcontroller, main frequency @ 1GHz;
• 512MB DDR RAM;
• 1GB NAND Flash;
• 4 serial ports, including 2 5-wire RS232 (DB9) and 2 3-wire TTL (20pin 2.0mm connector);
• 1 Ethernet port, 10M/ 100M auto-adaptive;
• 4 USB Host interface supporting USB2.0 protocol;
• 1 USB OTG interface supporting USB2.0 protocol;
• 1 high-speed SD card slot supporting up to 32GB SDHC card;
• 1 TF card slot;
• 1 SDIO WIFI connector;
• 1 CMOS camera connector supporting OV3640 3MP CMOS Camera;
• 1 HDMI interface;
• 1 CVBS output interface;
• 1 54pin LCD interface;
• 3 3.5mm Stereo audio I/O sockets, WM9714;
• 1 matix keyboard connector;
• 1 JTAG interface;
• 1 Active Buzzer;
• 4 LEDs;
• 1 18b20 temperature sensor;
• 1 infrared receiver;
• 1 reset button;
• 8 user buttons;
• Built-in RTC (Real Time Clock) with back-up battery;
• 1 SPI channel, 10pin 2.0mm connector;
• 1 IIC channel, 10pin 2.0mm connector;
• 1 A/D channel, connected to adjustable resistance for ADC testing;
• Dimension: 130 x 190mm
• Working Temperature: -10°C ~ +60°C
• Working Humidity: 10% ~ 95%
• GPS, GPRS, 3G, WIFI, CMOS Camera available as Add-on modules
Board support packages and sample programs are provided with source code, binaries, and documentations for Linux-2.6.35 Linux-3.0.8, Android 2.3 and Android 4.0.

Availability: The OK210-A ARM Cortext A8 development kit bundled with a 7” capacitive touch screen is available now for US$199.00 at Witech's official website http://www.arm9board.net.

 

What people think of ChromeOS and chromebooks

There have been many different takes on the Google's chromebooks since it was announced that products will soon be on the market. The review of the potential of the product is based upon each user's needs which makes it difficult to guage how it will effect the PC and laptop markets. Many of the writers and bloggers that are commenting are doing so with second hand knowledge and little or no market testing, this article will share how the chromebooks are being viewed by a beta user and multiple user groups that have been allowed to play on one of the Cr-48 chromebooks that Google sent out to beta testers.

Read more... Comment (0)
 

Nokia to adopt win mo... ? NooOOoOooOooooo!

I am a long time Nokia sufferer...  I love the N series.

First a N770 found it's way into my daily life, then a N810 for a few years..., which is now mounted in my car and tethers to my... N900 in my pocket & with me everywhere.

You might say that I like the N series Nokia device alot....it's a full blown Linux computer in my pocket.

At the same time, I think that Nokia sends a strong message that they hate us Nseries users but.....

Now, they are proving it...trying to imagine what is going to happen to Maemo and  Meego... after the Microsoft Nokia deal.

Maybe an Android is in my future?  Maybe even a 7" tablet..I can use Google Voice and Skype....

I will NEVER carry a Win-mo device... Never Ever.....not even for free...not even for a large monthly payment made directly to my Swiss bank account....

Someone said it best...   2 Chickens do not make an Eagle......

:-(

 

Android as mobile payment

With the Announcement yesterday (http://unplugged.rcrwireless.com/index.php/20101116/devices/5192/schmidt-android-2-3-gingerbread-to-include-nfc-for-fast-payment/) that android 2.3 will include RFID technology to allow touchless payment options I finally got scared. Yes, it may be a good idea to consolidate as many tools and functions as possible into a mobile device to save space and time, but this announcement seems too soon.

Read more... Comment (0)
 

Now It's Legal To Jailbreak or Unlock Your Phone (or any other device)

I always though Jail-braking or unlocking your phone (or any other device)  was not legal, but I was wrong.

Times reports that The Library of Congress' Copyright Office has officially deemed jailbreaking exempt "from a 1998 federal law that prohibits people from bypassing technical measures that companies put on their products to prevent unauthorized uses."

Apple can still say jailbreaking voids your warranty, but you're not doing anything illegal by jailbreaking your phone and installing apps not approved by Apple. Other good news: Unlocking cellphones (to use your phone with another carrier) was deemed legal in this ruling, as was circumventing DVD DRM to use the video for educational purposes, documentary film-making, and non-commercial videos. Check out a more in-depth analysis of the ruling over at Ars Technica.

Source: Electronic Frontier Foundation

 

Firefox "Home" Iphone

After 7 weeks Mozilla announce it, the Firefox home it's now on the Itunes Store. The Firefox home is not a web browser, instead is a synchronization plug-in for the activity in your pc, open tabs, bookmarks, etc.

Mozilla also has no plans to make a complete browser for Apple iOS, either. The company said previously that it opted not to port Firefox to the iOS platform due to limitations it said had been imposed on iPhone applications by Apple. Still, Firefox Home does work in concert with some Apple technology: Back in May, a Mozilla spokesperson explained to InternetNews.com that the Firefox Home viewer uses the iPhone's native WebKit rendering engine, and link information is then viewed with the Safari browser.

The Firefox Home application will work on Apple iOS versions 3.1 or higher and weighs in as a 2.4 MB download.

Source: It Management

 

Android 2.2 Better than iOS 4 in Javascript Performance

A tech site Ars Technica tested JavaScript performance on an iPhone 4 running iOS 4 and a Nexus One running Android 2.2. The results: Android 2.2 (Froyo) smokes iOS 4 when it comes to JavaScript, clocking in two to three times faster than iOS 4's mobile Safari.

Well, the Nexus One has to beat the iPhone. Nexus one is faster (1GHz CPU, vs. 600MHz for 3Gs, and 600-800 for iPhone 4), and these tests are basically CPU performance tests.

Source: Gizmodo

 
  • «
  •  Start 
  •  Prev 
  •  1 
  •  2 
  •  3 
  •  4 
  •  Next 
  •  End 
  • »
Page 1 of 4

Upcoming Linux Foundation Courses

  1. LFS426 Linux Performance Tuning
    08 Sep » 11 Sep - New York
    Details
  2. LFS520 OpenStack Cloud Architecture and Deployment
    08 Sep » 11 Sep - Virtual
    Details
  3. LFD320 Linux Kernel Internals and Debugging
    15 Sep » 19 Sep - Virtual
    Details

View All Upcoming Courses


Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board