18 Apr

Android and Microsoft (2015)


android-Microsoft-windows
(Image Source: Mario Tomás Serrafero)


I find this interesting: the recent move by MSFT to get into and “steal” the Android space.

Today, thanks to new leadership at MSFT (Nadella), it seems the company is entering a new phase — with new vision and no-or less ego than before.

And with this, MSFT is directly taking advantage of open source software to go after the Android market.

By leveraging the Android open source baseline from Google and investing around $70M in Cyanogen, it is going after the Android-based hardware (think Emerging/Global markets) independently of or not having to worry much about the underlying hardware/devices, while at the same time not depending or having to use Google Services and instead MSFT has the opportunity to introduce their own services and apps on Android-based hardware. A game changing strategy.

Very interesting indeed…

Thanks to Google for the Android Open Source Project which makes all of this possible. Google knew the risks and benefits, so did Sun Microsystems when it open sourced most of Java, and of course, let’s not forget the Linux core OS which triggered the OSS revolution and ecosystem. Open Source Software (OSS) is a beautiful thing…


Side note: It was around 2011 when MSFT made the initial deal with Nokia and many, including I, found it strange that Nokia would go the MSFT route — true signs of trouble within Nokia back then. Many of us asked ourselves why not go the Android way instead. But I believe ego and lack of vision (Elop/Ballmer) played a large role in the decision. MSFT ended-up acquiring Nokia as expected. Today, their combined market reach is tiny as expected, as compared to Apple and Google.

/ceo

18 Apr

On Android and Fragmentation (early 2014)

Due to its origins and philosophy with respect to openness, Android is a fragmented mobile platform. This is illustrated next:

android-platforms-early2014

There are different kinds of fragmentation to keep in mind.

Android platform versions. To minimize fragmentation-related headaches, decide early on what versions of Android to support. As you can see above, Gingerbread (introduced in 2011) still commands close to 20% of the Android device distribution (data above is gathered from the new Google Play Store app). It is important to keep in mind is that the more versions you support, the more testing and maintenance and related costs that you will have.

Multiple screen sizes. When creating an Android app, you will have to decide the kinds of devices to support, for example Smartphones, vs. Tablets, each with different sizes and resolutions, and provide the appropriate assets, fonts and layouts that ensures the best possible experience across such different screen characteristics. See Design Apps for Tablets (Android Developers Blog).

Hardware support. Another kind of fragmentation is related to hardware support, for example, the supported sensors and/or UI facilities. Not all devices are created equal and different device manufacturers decide what to include. A couple of examples: not all devices may support the same kind of camera, or may or not provide support for Bluetooth or for that matter, Bluetooth Low Energy (introduced with Android 4.3 (API Level 18). NFC may or not be there. Another example is the Kindle, which is based on Android 2.3 but it doesn’t provide support for many of the hardware sensors or UI facilities found on other Android devices.

Consistent UX Design. Maintaining a consistent design is not necessarily easy and can lead to a fragmentation user experience. Learn and follow the Android Design Guidelines. Google has done a great job documenting the best design guidelines for Android apps. From design principles, to styles and patterns, to building blocks, you should spend time going over these great developer resources by Google.

The good news is that as you can see on the pie-chart above, the market is consolidating on 4.x and newer and devices are getting more consistent. The whole Android reminds me of the Java Micro Edition and Sun Microsystems back then, which wanted to be open with great intentions, but that caused a lot of fragmentation and problems. The answer to this is to enforce consistency across. Google is attempting to do so by “Forcing OEMs To Certify Android Devices With A Recent OS Version If They Want Google Apps“. Let’s keep in mind that the main reason the iPhone and iOS have been so consistent with respect to platforms version, functionality and distribution, is because Apple owns the whole stack (hardware and software). But in an open platform, consistency is very hard to achieve, especially when there is competition within the ecosystem.

/CEO

Related to this see: 5 Tips to Get Started with Android Development.

16 Jan

Using Android’s Advertising ID

My most recent piece is about Using Android’s Advertising ID (Safari Online Books blog).

The ability to identify users is important for advertising, analytics and other purposes. Android developers typically rely on the Android Device ID or Telephony IDs such as the International Mobile Equipment Identity (IMEI) to uniquely identify users, but these approaches also introduce privacy concerns. Android 4.4 Kitkat introduces a new anonymous identifier for advertising purposes. Referred to as Advertising ID, it provides a user-resettable identifier that helps protect the user’s personal identity.

Read the rest of the blog Using Android’s Advertising ID

/ceo

23 Dec

On Location (and Other Sensitive) Data

Installing apps, Android in this case, is at times a bit of WTF. It shouldn’t have to, but it is. The amount of personal information that some apps gather can be extreme. This concern is especially true after Google removed the very necessary App Ops (permission manager) app.

Let me provide an example. An app that I recently installed asked for the following (and other) permissions:

Your location
precise location (GPS and network-based)

Your personal information
read your own contact card

Phone calls
read phone status and identity

Your social information
read your contacts

Your accounts
find accounts on the device

Not all apps need such amount of personal information. It is so important to gather just the information that is really needed, and nothing else. It is also very important to be responsible with things such as geo-fencing as well as having in place good privacy guidelines that are really in taken seriously.

A number of years ago I wrote a set of Guidelines for Location (and Other Sensitive) Data that that are still quite relevant. Check them out; I hope you find them useful.

/ceo

16 Dec

Android App Ops *WAS* a Step Forward

Android App Ops is no more…

Two weeks after I wrote Android App Ops is a Step Forward, Google has disabled/removed the permission manager. After the Android 4.4.2 update, invoking the App Ops app results in a RuntimeException.

The R.I.P. permission manager, a very important capability for end-users, WAS a step forward; we are going backwards here.

Google’s response for why they removed this capability (via ReadWrite) is as follows:

Since Google never supplied documentation for the accidental release of the permissions manager, Android developers had no opportunity to prepare for the possibility that users might be withholding individual permissions, or to warn users about the possibility that an app might break if they did so.

OK. I do understand the rationale — I covered similar concerns when I wrote my original blog on App Ops:

This will require that developers be aware and properly test for scenarios related to restricted features/APIs not being available, and perhaps new documentation related to permissions guidelines for developers.

Seems the whole thing was not given proper thought.

It is of extreme importance to end-users to re-add this winning capability as soon as possible.

Here is EFF’s response to this debacle:

The disappearance of App Ops is alarming news for Android users. The fact that they cannot turn off app permissions is a Stygian hole in the Android security model, and a billion people's data is being sucked through. Embarrassingly, it is also one that Apple managed to fix in iOS years ago.

This debacle should be temporary. Google, please re-enable this ASAP.

/ceo


Related to this:

* Android App Ops is a Step Forward

* Google Kills A Cool Privacy Feature In Android That It Didn’t Intend To Release (ReadWrite)


LogCat when invoking the App Ops permission manager (Android 4.2.2):

12-15 11:32:41.004: E/AndroidRuntime(12663): FATAL EXCEPTION: main
12-15 11:32:41.004: E/AndroidRuntime(12663): Process: com.android.settings, PID: 12663
12-15 11:32:41.004: E/AndroidRuntime(12663): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.settings/com.android.settings.Settings}: java.lang.IllegalArgumentException: Invalid fragment for this activity: com.android.settings.applications.AppOpsSummary
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2195)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.ActivityThread.access$800(ActivityThread.java:135)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1196)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.os.Handler.dispatchMessage(Handler.java:102)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.os.Looper.loop(Looper.java:136)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.ActivityThread.main(ActivityThread.java:5017)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at java.lang.reflect.Method.invokeNative(Native Method)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at java.lang.reflect.Method.invoke(Method.java:515)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at dalvik.system.NativeStart.main(Native Method)
12-15 11:32:41.004: E/AndroidRuntime(12663): Caused by: java.lang.IllegalArgumentException: Invalid fragment for this activity: com.android.settings.applications.AppOpsSummary
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.preference.PreferenceActivity.switchToHeaderInner(PreferenceActivity.java:1180)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.preference.PreferenceActivity.switchToHeader(PreferenceActivity.java:1199)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.preference.PreferenceActivity.onCreate(PreferenceActivity.java:545)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at com.android.settings.Settings.onCreate(Settings.java:207)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.Activity.performCreate(Activity.java:5231)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2159)
12-15 11:32:41.004: E/AndroidRuntime(12663): 	... 11 more
12-15 11:32:41.014: W/ActivityManager(611):   Force finishing activity com.android.settings/.Settings
27 Nov

Android App Ops is a Step Forward

Update Dec/15/2013: Two weeks after I wrote this piece below, Google removed App Ops... See Android App Ops *WAS* a Step Forward, and stay tuned.

One of Android’s top limitations, one that totally drives me nuts, is its security model, in particular the app permissions model. This is a permission security model where developers (the app) requests permissions, and the user grants permissions during the installation process.

To get an idea of how the Android security model works in general, see an old article of mine titled Understanding security on Android (IBM developerWorks).

The problem with Android’s permission model today is that users are limited two options: 1) grant ALL requested permissions, or 2) not install the app at all.

…and that is a sucky permission model that needs revision.

For example, if I liked a new cool camera app, one that accesses the camera and my location, but I do not want the app to track my location, I have to compromise – either I grant all the permissions, including the ones I am not comfortable with granting, and if I don’t like that, even though I may like the app itself, the alternative is not to install the app at all.

Enter App Ops (Permission Manager)

It was with great excitement (yes, sounds geeky) when I learned about the native App Ops app.

I had totally missed the native App Ops app in Android 4.3 that allows users to grant individual permissions post-app installation. Then I learned the app was removed on Android 4.4. But the good news is that it was not removed, it was just hidden. App developers such as Color Tiger allows you to unhide the native App Ops app. With the native App Ops app I can now control and turn off specific permissions per app!

This of course means that apps must be robust and properly handle the unavailability of restricted, un-granted features — by properly testing for null values and handling security Exceptions — vs. just crashing when it cannot perform the (restricted) functions that have been turned off by the user. Perhaps this is the reason the native App Ops app was hidden by Google for now.

I did a quick test on my Nexus 4 (I finally got my Android 4.4 upgrade) – wrote a simple location-based app/activity and put some breakpoints to test/see this behavior while turning the location permission on/off via the native App Ops app.

Permission Test screenshot

In the case of the LocationManager.getLastKnownLocation(), turning off the Location permission, it returns a null value (which means that the provider is currently disabled). Note that I was expecting a SecurityException to be thrown instead! Hmm, need to think about that. Thus, I will continue researching this and in the meantime, for LocationManager.getLastKnownLocation() seems that all we have to do is to test for null, something you should be doing anyways.

Location loc = locMgr.getLastKnownLocation(LocationManager.GPS_PROVIDER);
if (loc == null)
    return; // Provider is not enabled

In summary, while the native App Ops app is a step forward (for end-users that is), the selection of permissions to grant for a given app, really should be part of the app installation process itself (an alternative is to prompt the user every time the app attempts to use a restricted API – I think I prefer the former). This will require that developers be aware and properly test for scenarios related to restricted features/APIs not being available, and perhaps new documentation related to permissions guidelines for developers. I am looking forward to see this happening.

Oh, and thank you, Color Tiger!!!

/CEO

12 Nov

Enabling Voice Communication on Android Apps

Check out the new guest post that I wrote on Enabling Voice Communication on Android Apps, for the Safari Books Online blog. It covers how to enable voice communication using the Android SIP Stack/API.

Enabling voice communication on Android apps is possible via the Session Initiation Protocol (SIP) stack. This protocol originated in 2000 as a signaling protocol in support of Voice over IP (VoIP). With today’s move to IP wireless networks such as LTE, SIP is the core signaling protocol for voice over IP Multimedia Subsystems (IMS). In this post we will explore how to enable voice communication on Android apps by using the Android Session Initiation Protocol (SIP) stack. With the transformation of traditional networks as IP-networks, and the future of voice as a “data app,” expect media-rich and location-aware communication apps, where the smartphone plays a central role in personal communications. This means that developers can now create a new breed of voice communication apps like never before. This post assumes you are somewhat familiar with the Android platform and the Java language.

Read Enabling Voice Communication on Android Apps (source: Safari Books Online).

ceo

04 Nov

Android 4.4 (KitKat) is Here!

Check out the new guest post that I wrote on Android 4.4, for the Safari Books Online blog. It summarizes what is new on Android and related important information.

In this post we will explore the major changes introduced in Android 4.4. Android 4.4 is the newest version of the Android mobile operating system that was released at the end of October 2013. Also known by the codename KitKat, this version brings a number of very important internal memory-related improvements as well as improvements to the user interface, connectivity support, media and security support, and more.

Read Android 4.4 (KitKat) is Here! (source: Safari Books Online).

ceo

21 Nov

Article: Parse cloud-based services for Android apps

My latest article on Mobile & Cloud computing…

Summary: Explore the advantages of storing mobile application data in a private cloud with this introduction to the Parse SDK for Android. Mobilist C. Enrique Ortiz introduces the Parse API classes for cloud-storing and manipulating users, data objects, and files for your mobile applications.

See Parse cloud-based services for Android apps (IBM developerWorks).

29 Sep

Android Platform Versions (2012)

Below is a snapshot of the Android platform distribution, as of September 2012.

Android Platforms Sept 2012

As you can see, the majority of the devices out there, close to 60%, are still 2.3 (Gingerbread). This is followed by ICS with close to 21%. Froyo 2.2 is 14%.

I hope that by March (but more likely, summertime or later) of 2013, that by then the majority of the Android devices out there are 4.0+. This would make the Android app developer’s life in general much simpler — by (1) minimizing the number of major Android platforms to deal with, and (2) making it easier/cheaper to implement (or move up to) the recommended Android design guidelines. The result of this includes (1) cheaper to develop/maintain apps, (2) consistent apps per developer, and (3) consistent look/feel/behavior across the app market.

For this to happen, device manufacturers and operators must help transform the above piechart to be mostly 4.0+ Android devices. They can help by literally selling less (and even better, stop selling) Gingerbread/2.3 and older devices. If you look around you will see that operators are still selling Gingerbread devices. And we need Google to have more cojones with respect to this and stimulate, if you will, both the device manufacturers and operators to move forward — this transition is taking forever! (Note: Gingerbread was introduced on December 6, 2010.)

Some customers may leave feedback as “why the app does not follow the Android UI guidelines”, or “why the app doesn’t support the ICS UI paradigm” — but again, 4.0+ is just a smaller fraction of what is out there!

In the meantime, there is the Android Support (Compatibility) library. Also, see Backwards Compatibility (Android Design Patterns).

ceo

31 Jul

On SmartTVs: The Vizio Co-Star (2012)

Vizio Co-Star is NO-GO.

Part of creating a product is providing proper customer support throughout its life-cycle. A product life-cycle begins with product envisioning, followed by definition, followed by create/build, followed by going to market (which on itself consists of different aspects including customer support).

Vizio has failed to deliver my product. And has failed to make *me* a satisfied customer — after waiting for almost a month for the delivery/return-process to work itself out, they could have sent me the package again, perhaps with rush delivery for all the troubles I have been through. But they claim they cannot do that (I don’t believe them); they should take a lesson from Zappo’s book. Instead they will refund me and I have to reorder. But I won’t reorder. Maybe their Co-Star is a kickass product, maybe it is not; the only way I am reviewing the Co-Star is if they send me one. In the meantime, I will continue using my Android tablet for Netflix streaming and apps on my TV. I will wait for a competing Android TV product, and maybe I will end up buying an Apple TV.

Read more on the comments section.

I will categorize this one under “#FAIL”.


I believe SmartTVs will open new/great opps for content/developers; and this will be especially true when intersecting this w/ Mobile.

So, to begin researching this in more detail, I’ve ordered Vizio’s Co-Star. Based on Google TV (click on the previous hyperlink to see the specs) it has everything needed to play/hack-away.

Crafted by VIZIO’s years of entertainment expertise, Co-Star packs the powerful features of Google TV into a sleek, intuitive interface. Combining live TV, the Web and apps into one experience, it allows you to search and access content from all of them without interrupting your viewing.

Of special interest to me is the combined experience across TV & apps that the Co-Star supports; think about it, your app overlaid on top of the video stream — if this plays out as I hope, this is very, very, very powerful, and is what I’ve been waiting for:

  • Merges live TV, web, and apps into one interface
  • Search across live TV, web and apps – simultaneously
  • Picture-In-Picture – Apps & Live TV

Price: $99 — great price.

So stay tuned; I will report back…

ceo

23 Jul

Starbucks App == Mobile + Convenience

The Starbucks App for Android 2.0 is out on Google Play (see announcement on VentureBeat).

Good to see…

(I was one of the people who contributed design & dev to this product, specifically the Card Management tab/functionality, plus some other.)

Starbucks have proven, starting with their iOS app, that consumers are ready for mobile payments — as of April 2012, Starbucks apps have done over 42M mobile payment transactions (see announcement on VentureBeat).

Awesome…

Convenience is always a big winner. In the case of Starbucks it is about payments, rewards and store information right on the palm of your hands.

There is another important aspect here. It also shows that stores must have the whole infrastructure in place to be successful:

  1. The POS that are enabled with the appropriate readers and software,
  2. The devices/smartphones with the SW and functions (the apps), and,
  3. The scalable service infrastructure with the appropriate back-end integrations, and the right kind of services-and content — in the case of Starbucks, authentication, payments, rewards, store information and related-integrations.

It is then that users will adopt this in masses; and, yes, it is about convenience.


(Card management tab with Pay Now, and embedded PayPal Integration for Card Reload)

Digital cards are at the center of the app. The app, which is global-ready, allows smartphone-users to load the digital cards (dollars, pounds, etc, depending on country) via credit cards and/or PayPal — all within the app, thus maximizing the user experience. The digital cards are then scanned at the stores. For this, the app uses 2D-barcodes that are scanned/read by the POS using regular barcode scanners, consummating the transaction.

Looking forward, this app is a good candidate for NFC and/or other proximity-based technologies. If the NFC infrastructure was in place, that is, the readers and the NFC-capable smartphones, I will bet that it would also be a winner. But full, pervasive NFC deployments are still are a few years away, delaying its adoption. As a result, today, 2D-barcodes is the way to go.


(This is not real, just a concept scenario that I put together for the Starbucks app with NFC support)

As mobile app designers, the important thing is to design your application in a way that 2D-barcodes or NFC or other are just interaction channels — the key is keeping the rest of the app- and related supporting infrastructure (servers, authentication, exposed services, payment infrastructure and so on) properly abstracted. As a side note, this is a reason why Square is ready for the future — it has all the infrastructure in place, and today their reader is the Square-reader, and tomorrow it can be something else. Starbucks is ready too.

ceo

14 May

Android Dev Austin (May 2012) | Topic: “Android app performance and analysis”

Update: we had a great event! — see some photos of the event. Thanks to our speakers, and to our sponsor Evernote.


Topic – “Android app performance, optimization and analysis”:

For headcount purposes, please register at http://www.eventbrite.com/event/3493177187

Food and drinks will be served.

We have some goodies to give away, courtesy of Google’s Developer Advocate group.

Event Info:
Date: 5/24/2012
Time: 6:45-9pm
Where: Evernote Corp. 6504 Bridge Point Pkwy, Suite 400 Austin, TX. 78730

Agenda – “Android app performance, optimization and analysis”:

0 ~ Intro, and a word from our sponsor, Evernote
1 ~ The Evernote Android SDK
2 ~ Using the Memory Analyzer tool to find memory leaks/inspect memory usage, including soft vs weak references (useful for memory analysis), and using the built in Android profiler to find performance hotspots
3 ~ Introducing CoreDroid (An OSS app framework to ease up some of the pain of app development)
4 ~ Android Performance monitoring and configuration SDK with InstaOps (mobile application performance monitoring and configuration management system)
5 ~ Open discussion

Also, if interested, you may want to bring your computer — the folks from InstaOps will also explain how developers or dev-ops can use InstaOps’ SDK and tools to improve mobile performance. So if you are interested into diving into the code (including code walk through), please bring your laptop.

Thanks to our sponsor, Evernote.

And thanks to Google’s Developer Advocate group for the goodies/give aways.

For more information visit the Android Dev Austin website.
ceo

05 May

APIs and Copyrights (Oracle vs. Google)

The Oracle vs. Google case on Java is such a precedence case that any ruling on APIs vs. copyright might open a can of worms. The outcome of this ruling literally will affect any software company and developers designing APIs (and protecting those as Intellectual Property).

(I personally believe programming languages and its APIs should not merit copyright protection — languages are the means of unique expression, not the expression itself).

In the meantime, Europe courts just ruled on this exact matter (SAS Institute Inc. v. World Programming Ltd) against copyright.

A couple of key quotes from the article Oracle V. Google Jury Deadlocked? (Information Week):

“Google’s position is that APIs, like computer languages, cannot be copyrighted; Oracle disagrees.”

“…if the jury finds that Google infringed and that Google’s actions don’t qualify as fair use, then the copyrightability of APIs comes into play.”

“The primary issue that might be made moot is whether Oracle can even make a copyright claim. The judge has made clear that he reserves the right to rule on whether APIs can be copyrighted under the law. But presumably, he’d rather not if there are other means to resolve Oracle’s claim. If Google is found not to have infringed, he doesn’t need to rule on the copyrightability of APIs. If Google is found to have infringed, but to have done so as permitted under the fair use doctrine, he also doesn’t need to rule on whether APIs can be protected.”

Above: note how the judge is trying to avoid having to deliberate on APIs and Copyright; trying to stay away of such “debacle” and its consequences.

On Thursday, that very question was resolved in Europe: The Court of Justice of the European Union ruled in a similar case, SAS Institute Inc. v. World Programming Ltd, that neither the functionality of computer program nor the format of its data files are expressive enough to merit copyright protection.

Read the whole article Oracle V. Google Jury Deadlocked at Information Week.

ceo
(Happy Cinco de Mayo)

01 May

Oracle vs. Google on Java (2012)

Some background: I spent many years as an individual contributor to a number of J2ME expert groups including MIDP 2.0, MIDP 3.0 and a number of J2ME APIs ~ around 10 different JSRs over 8+ years. I was a huge proponent of Java for mobile and still am.


In the next couple of days, the jury will decide in the trial of Oracle vs. Google on Java.

The Google vs. Oracle Java debacle is in my opinion, for the most part, the result of how Sun left behind a loosely defined and ambiguous Java, from the perspective of open source software (OSS).

To attract developers and win the community, Sun played the OSS “game”; but did it partially. I recall Schwartz claiming Java as open source, then trying to understand GPL classpath exceptions and whatnot.

Then Google started Android with Java, and Android became very successful.

As Sun shopped themselves around, Oracle, a coined-operated company, clearly understood the monetization opportunity that presented itself with Java and its state.

And here we are today.

Everyone in the business of SW knows that 3rd party SW must be licensed. The questions are “what is SW?”, “what requires a license?” and “what is up for fair use?” Is it the Java Programming language and related core APIs? The Virtual Machine and related bytecode? What about all the APIs developed by the Java Community and led by other companies such as Nokia and Motorola and others? All the above?

Google made a bet and decided to take risks — perhaps based on Schwartz’s OSS claims or the claims from the JCP vs. “fair use”.

But soon the court will decide, and all this will be over. Google may have to pay a lot of money for using Java, or maybe not, or maybe some kind of IP + $ arrangement is done between the companies, or maybe Google ends up using a different programming language on top of their VM.

ceo

16 Aug

On Google’s Moto Mobility Group Acquisition

The latest big news on Android is Google’s acquisition of Motorola’s Mobility group.

And I have to say, I wasn’t expecting that one.

The main arguments floating around on the acquisition are:

  • Patent play, driven by the patent war including the recent Nortel patent acquisition by Google’ competitors
  • Hardware play, which better positions Google against Apple

My thoughts

  1. It is a patent play
  2. TBD is the impact of this on Google/Android partners — this is huge with respect to Android partners, creates a love-hate relationship, and definitely will have a negative impact on their partners, their growth, their confidence, and as a consequence, will affect Android’s growth; it is the way things work. While Android’s global growth was leveraging big manufacturers such as HTC and Samsung, now, unless some kind of awesome agreement is done with the partners (see last bullet), Android’s success has now reverted mainly onto Google’s shoulders
  3. Google must to decide very fast what they want to be: a SW or HW-or both kind of company
  4. Google *must* keep the IP for the patent wars, and spinoff Motorola as a subsidiary — running a HW company is just a different kind of beast.
  5. While maintaining ownership of the new IP, Google shall give royalty-free access of the Motorola patent portfolio to Open Handset Alliance (OHA). This will 1) provide incentives to existing OHA partners, 2) provide incentives for new partners to join OHA, and 3) allow OHA and Android to continue its growth path and benefits to OHA partners

Pretty unexpected, but very interesting move by Google indeed. We are witnessing a major reshape of the mobile industry from software to hardware; from Nokia and Microsoft, to Goggle, Motorola, the impact on APAC-based device manufacturers, the operators, Apple, and so on.

This counter-offensive by Google will or should help battle the potential new costs to consumers due to patents wars. As a side note, now imagine how much innovation (and quality of innovation) would be possible if instead of having to spend so much cash on patents, instead it is invested on people, their research-and-ideas, and thus true innovation.


Update Aug 16, 1:30pm: Android partners “welcome” Google’s Motorola Mobility buy (VentureBeat). Very interesting to see Android partners are welcoming this. Maybe they were consulted? (unlikely). But it means that today they see the ROI and are so committed to Android that as long as Android itself is less risky (due to more IP protection), then they are OK with some competition. And/or maybe they don’t see Motorola itself as a real threat. If the latter changes where Motorola becomes a threat, we obviously will see a change of heart.

Update Aug 16, 2:30pm: Google: We Bought Motorola To “Protect” The Android Ecosystem (Business Insider)

Update Aug 22: Android vs Windows Phone 7: At least one handset maker thinking about it (GigaOM)

ceo

15 Feb

Reminder: Android Dev Austin | Feb 17, 2011

A reminder that our next Android Dev Austin meeting is this Thursday Feb 17 at 6pm, at the T-Mobile offices.

Sponsored by T-Mobile, we will have an overview of T-Mobile’s integration of WiFi calling into Android devices followed by open format with local Android developers who will share with us their recent experiences developing and publishing their Android apps, plus open discussion. If you want to present, just come prepared to do so.

Mark your calendars, and see you this Thursday…

PLEASE REGISTER (for headcount purposes) at http://androiddevaustin.com

  • When: Feb 17, 2011
  • Time: 6-8pm
  • Where: T-Mobile offices at 3801 S Capital of TX Hwy Ste 300 Austin, TX 78704 – see map
  • Cost: Free! Food and drinks will be served!

Scan the following QR Code to retrieve the map to our next meeting:

PLEASE REGISTER (for headcount purposes) at http://androiddevaustin.com

ceo

09 Feb

Android Dev Austin | Feb 17, 2011

A quick heads up that our next Android Dev Austin (@androiddevaus) meeting is on Feb 17 at 6pm, at the T-Mobile offices.

Sponsored by T-Mobile, we will have an overview of T-Mobile’s Android strategy followed by open format with local Android developers who will share with us their recent experiences developing and publishing their Android apps, plus open discussion. If you want to present, just come prepared to do so.

Mark your calendars, and please stay tuned for more information…

PLEASE REGISTER (for headcount purposes) at http://androiddevaustin.com

When: Feb 17, 2011
Time: 6-8pm
Where: T-Mobile offices at 3801 S Capital of TX Hwy Ste 300 Austin, TX 78704
Cost: Free!

PLEASE REGISTER (for headcount purposes) at http://androiddevaustin.com

ceo

15 Dec

Article: Introduction to Facebook SDK for Android

Write Facebook apps for the Android platform with the Facebook Android SDK…

You can incorporate Facebook functionality into your own applications. From the mobile perspective, the Facebook Platform supports APIs for mobile web applications, and mobile SDKs for native mobile applications for the iPhone, iPad, and Android platforms. In this article, explore the Facebook Platform APIs and the Facebook SDK for Android, the SDK released by the Facebook mobile team.

See my article Introduction to Facebook APIs (IBM developerWorks) which introduces the Facebook SDK for Android.

ceo

30 Nov

Article: Understanding Android local data store APIs

“The ability to store data locally on the mobile device is a critical function for mobile applications that are required to maintain essential information across application-executions or the lifetime of the application. As a developer, you constantly need to store information such as user preferences or application configurations. You must also decide if you need to tap internal or external storage, depending on characteristics, such as access visibility, or if you need to handle more complex, structured types of data. Follow along in this article to learn about Android data storage APIs, specifically the preferences, SQLite, and the internal and external memory APIs.”

See my article Understanding Android local data store APIs (IBM developerWorks) which introduces the different local data store APIs on Android.

ceo

24 Nov

Next Android Dev Austin | Dec 7, 2010

Folks, after a quiet, busy time, we finally have an Android Dev Austin scheduled for Dec 7, 2010; mark your calendars.

>> PLEASE RSVP for headcount at http://androiddevaustin.com <<

Topic: The State of the Android OS & Native vs Non-Native

Where: Motive offices (see http://Motive.com)

When: Dec 7, 2010. 6:00 pm. Please arrive by 5:50pm

Cost: Free. Sodas and Pizza will be served; maybe beer too!

Speaker: Pat Dalberg of Mutual Mobile. Pat is a Sr. Android Developer at Mutual Mobile. Pat Dalberg has worked with clients such as Dell, Gowalla, Google, Del Monte, DailyBurn etc. Mutual Mobile is an Austin based consulting company that architects, designs and develops mobile products for forward thinking companies.

For more information and registration please visit http://androiddevaustin.com/.

ceo