Droid Sector

Roebeet from a Notion Ink Hacks forum has compiled an update.zip file that enables root access for applications and installs Google apps.

This is just an offshoot to Rothnic’s excellent work:

Alpha 1 Link: http://www.mediafire.com/download.php?63pusp22o7ho9mo

This is essentially the Gapps /root work that Rothnic has already done, with a few extras:

• adhoc added
• Transparency on the status bar added (taken from here, thanks GTO777!)
• Frame buffer bump from 50 to 60. Should improve the screen slightly, and bump up performance slightly.
• Titanium Backup friendly Busybox
• Removed the Chinese and Froyo keyboards, adds the Gingerbread keyboard
• SuperUser, YouTube apps added
• A Home Switcher and Live Wallpapers added. That’s in case you prefer a different launcher.

Video by FreezerBite:

A CEO of Blue Frog Gaming talks about Android fragmentation:

One thing I always hear when reading about mobile development is fragmentation. Steve Jobs, who talks about Android so much because he isn’t worried about it, harps on it relentlessly. Just today I read, on an Android blog, the following quote:

“In an iOS world, you only have to write code once and know it is optimized for every phone that’s been sold.”

Bahahahahaha. Yeah right. I do iOS development, and let me tell you, fragmentation there is a huge problem. First off, there are different OSes on different devices. Here’s a chart of that:

Compare that to Android:

Pretty similar. Android in this case has the benefit of having fewer OSes in play.
Read more…

Android developers are now required to upload a hi-res application icon (512×512 px) when publishing an application.

Also, the following additional fields are now available:

• Promotional Video (YouTube URL)
• Feature Graphic (1024×500 px)

Judging by the graphics resolution, these assets will be used in a long awaited web-based Android Market.

Update: a confirmation message from Android Market support team:

Finally, we are adding support for larger promotional graphics to showcase your application. In addition to the currently required app screenshot, you will be required to upload one “feature” graphic. Supported promotional assets will now include:
- A “feature” graphic, landscape aspect ratio, 1024 x 500 (required).
- A high-res icon, 512 x 512 (required).. The Android icon design guidelines located at http://developer.android.com/guide/practices/ui_guidelines/icon_design.html apply.
- 2 screen shots, 320w x 480h, 480w x 854h, or 480w x 800h, increasing to 8 screen shots in the future (1 required).
- A link for a promotional video hosted on YouTube (optional).

A great post by Shantanu Goel on the openness of Android:

Android and Open Source: Allegations and Answers

Allegation: Google does a lot of development in private for few months and then releases the code to public.

Answer: Almost every open source project I know does this. Do you think every person who works on an open source project pushes his code to the mainline 10 times when re writes a 10 line code? No. He completes the feature, tests it and then pushes it out. Individuals might do it sooner, companies might do it later but everyone pushes out their code when they feel things are fairly ready. So, Google choses to do the “push” every few months when they think their new feature set is ready. This, of course, is more influenced by the fact that they need to be competitive in the aggressive mobile market and hence not let the competitors know about the exact features but still it is well within the limits of open source. And they are doing it before/with the binary release as well.

Allegation: Only google employees can check in code to mainline.

Answer: Every open source project has only a select few folks who can check in code. Most of the open source projects start with only their founders having commit access. They may or may not give commit accesses to anyone else. Check out various open source projects on sourceforge, googlecode, etc and you will find this. Most of the projects that do choose to give commit access to others, start doing it after some time when they feel the project is mature enough and they are confident enough in someone else. Android is just a hatchling, around 2 years old. It has begun making strides only now so Google may even choose to take the latter path but I can understand if Google wants to keep this as their control point because of the hustle and bustle of the mobile OS world which is much more rapid and cut throat than the desktop OS and this does not make them closed. Not only that, but seeing how everyone in the mobile world is so trigger happy with suing everyone else, it creates a legal issue for them as they would be the ones to answer if someone else brings this upon them.

Allegation: Google only accepts their own code into official android and nobody else’s.

Answer: This one is hilarious. Obviously, anyone who says this hasn’t actually been to review.android.com. Just go their and check whether any merged changes have non-google, non-android email ids. Anyone can upload their patches there but the accepted ones are fairly low. This problem is present in every popular open source project, even the Linux kernel. But is more pronounced in the case of android because Google’s android team is much smaller than the number of persons working on other projects and there is red tape of a big company involved. If you want to get your patch in, just like the kernel, you need to engage with them. Talk to them in the relevant bug report, comment the code properly, give them a reason to not avoid your patch. But yes, the process is still very slow and it is eons faster to just contribute to a fork like cyanogenmod. I do hope that google does get better in this regard soon though.

Allegation: It is not possible to make a full android build from the public code tree of android.
Answer: BS. Cyanogen does just fine with his full AOSP builds. People argue that Google does not release the modem/baseband code but they idiotically fail to realize that the baseband code is not part of Android at all. It is the IP of the baseband manufacturer and is specific to each hardware. Android is just the code that runs on apps hardware. Google does not indeed release the code of their built in google apps (gtalk/gmail etc) though but they are already working towards that and these apps will not be a part of the base Android system anymore. These would be standalone apps and even now you don’t need them to make a fully working android build.

Allegation: “Android” is a registered trademark and is held by Google.

Answer: LOL. Linus holds the trademark for “Linux”, Mozilla foundation holds the trademark for “Firefox”, Canonical holds the trademark for “Ubuntu”. Get the drift?

Allegation: Google doesn’t stop the carriers/OEMs from locking down the phones, adding bloatware or custom UIs.

Answer: This is an issue with carriers/OEMs and not Android. Google uses the apache software license (ASL), which is a permissive license (like MIT, BSD, etc) and hence does not stop the carriers from doing such a thing (In fact, this is the very foundation of being open, check the next passage about OSI foundation, point no. 9). Many people say they should, but if they did then they wouldn’t be open anymore, would they?
Even Linus Torvalds is against making such a stipulation of not allowing locking of phones and this is the biggest reason why the Linux Kernel (and lot of other open source projects) didn’t move to FSF’s (Free Software Foundation) GPL v3. I wonder why no one calls the Linux kernel closed hmmmm…
BTW, if you are so serious about unlocked/rootable phones then buy a dev phone directly from google or get one from Synapse.

Android and Open Source: OSI Foundation

The OSI foundation has a few guidelines to determine whether something is open source or not under their Open Source Definition. Android uses the OSI compatible Apache Software License (ASL) but still let’s see whether Android comes up to all of them or not. If it is in conflict with even one of the requisites, we will call Android closed.
1. Allow free redistribution – Check
2. Give out un-obfuscated source code – Check
3. Allow modifications and derived works – Check
4. Allow distribution of modifications (as patches) or modified software as a whole. Can restrict the modified versions from using original name of software – Check
5. No discrimination against any person or groups – Check
6. No restriction of using the software on any device or field – Check
7. No additional license needed – Check
8. No product-specific license – Check
9. No restriction on software distributed along with original software – Check
10. Technology neutral, i.e., no preference for an individual technology or user interface – Check
So, Android is true to each and every point that being open demands to it. In fact, points 9 and 10 are fundamental in making it open but alas, people less oriented with open software tend to term this as being closed (as seen in the last allegation above)

Read the full post: http://tech.shantanugoel.com/2010/10/25/android-open-source-or-not.html

Twitter client [TweetDeck] recently launched their app for Android. They reported that they had to contend with more than a hundred different versions of Android software on 244 different handsets. The multiple hardware and software iterations present developers with a daunting challenge. Many Android apps work only on selected Android handsets, running selected Android versions. And this is for handsets that have been shipped less than 12 months ago! Compare this with iPhone, where there are two versions of the software, the current and the most recent predecessor, to test against.

Iain Dodsworth, the CEO of TweetDeck, has responded via Twitter:

• Did we at any point say it was a nightmare developing on Android? Errr nope, no we didn’t. It wasn’t.
• @dannysullivan yes exactly! We only have 2 guys developing on Android TweetDeck so that shows how small an issue fragmentation is

I would like to add that we also had no problems with Android development. In most cases you just need two sets of graphics for middle-res and hi-res devices. Our apps have more than one million downloads combined, and we received no reports yet about problems with specific devices.

In addition to Google’s own app marketplace, Amazon, Verizon, and Vodafone have all announced that they are creating their own app stores for Android. So there will be at least four app stores on Android, which customers must search among to find the app they want, and developers will need to work with to distribute their apps and get paid. This is gonna be a mess for both users and developers.

Contrast this with Apple’s integrated App Store, which offers users the easiest-to-use largest app store in the world, preloaded on every iPhone.

The app stores from Amazon, Verizon and Vodafone do not exist yet, while there are already two stores for iOS – App Store and Cydia (which contains applications that have been banned by Apple). The Android Market will stay the biggest source of apps, because of a $25 one-time fee and no censorship. In other words, there is no reason for the developers to ignore the Market.

And we also think that our developers could be more innovative if they can target a singular platform, rather than a hundred variants. They can put their time into innovative new features, rather than testing on hundreds of different handsets.

Developers can simply use the Nexus One or similar phone as the main testing device, it will cover 75% of devices available on the market. Create one or two virtual devices in an emulator to make sure that your app will work properly on Android 1.6 (16%) and 1.5 (9%). So, basically, we are dealing with 2-3 versions of Android, not with some “hundred variants”.

One naturally thinks that a seven-inch screen would offer 70 percent of the benefits of a 10-inch screen. Unfortunately, this is far from the truth. The screen measurements are diagonal, so that a seven-inch screen is only 45 percent as large as iPad’s 10-inch screen. … This size isn’t sufficient to create great tablet apps, in our opinion.

iPad now has over 35,000 apps on the App Store. This new crop of tablets will have near zero.

Well, Samsung did tablet versions of Gmail, calendar and phone book. Developers can use the provided addon to emulate the Tab and test/tweak their apps.

Maybe its screen is not big enough to create full-fledge tablet apps, but this is also means that most apps from the Android Marketplace will run just fine and the Tab will have about 100,000 working apps on launch.

iPad too did not have many apps in the beginning. Twitter for iPad was released only in September, Skype still does not have an iPad version!

The Samsung Tab has many strong points: it’s smaller and lighter (good for an e-reader device), has cameras, Flash, widgets and more.

If you’re an Android developer, please make sure that your app will work properly on the Galaxy Tab. The best way to do this is to create AVD with an add-on provided by Samsung.

To download it:

• Run the AVD Manager and select Available Packages in the left panel.
• Click on the “Add ADD-on Site” and enter the URL below.
  http://innovator.samsungmobile.com/android/repository/srepository.xml

A detailed guide and development tips is here: http://innovator.samsungmobile.com/galaxyTab.do

An analyst today agreed that Android Market apps running on the Galaxy Tab’s 7-in. screen with Android 2.2, also known as Froyo, won’t look good. Since Froyo was intended to be used on smartphones with smaller 3-to-4-in. screens, images on a tablet running Froyo will appear stretched or out of focus, pixilated or with jagged edges, said analyst Rob Enderle of Enderle Group.

If images will appear out of focus, I would suggest this analyst to get a new pair of glasses. A basic knowledge of Android OS also won’t hurt.

The Galaxy Tab has a resolution of 1024 by 600 pixels, which is a little bigger than 800×480 of most modern smartphones. Not twice bigger, so there’s no need for higher resolution graphics. It will use the same (hdpi) UI graphics as in Nexus One, EVO or Galaxy S phones.

It’s important to understand that Android will not scale the entire screen image as on the iPad (this is also known as “pixel doubling”). The Android UI has a “fluid” design, like that on many web pages.

Just check out the image below:

Even if an app was not designed to support large screens, it won’t “look ugly”. It will be displayed in the middle of the screen surrounded with black borders. To fix this, developers should add the following string to the AndroidManifest.xml file:

supports-screens android:largeScreens=”true” android:anyDensity=”true” more…

Samsung will also provide has provided developers with custom AVD and skin as an SDK add-on. I don’t have it yet, but these screenshots below, taken from an emulator with a resolution of 1024×600, will give you an idea how Android apps will look like on the Galaxy Tab.

Tweet from the person who actually have the tablet:

Seriously, it’s great that you can develop Android apps on a Mac just as on Windows and Linux.

Let’s create a simple Automator app to make installing apk files a little easier.

• Download the Android SDK for Mac and extract it to an Android folder in your home directory.
• Launch Automator and create a new application.
• Add an action “Run Shell Script” with a sh shell.
• Paste this command: ~/Android/android-sdk-mac/platform-tools/adb install -r “$1″
• Add another two actions shown below if you want a feedback from the script.
• Save the application to the Applications folder.
• Associate apk files with your new application.

Now you can install Android apps by double clicking on apk files.

Download: Automator App.

Update: adb now stored by default in platform-tools folder, please check location of adb file on your computer. You can also drag adb file from Finder to Automator to insert the complete path.

In case of problems, open Terminal app and run command adb devices. You should see an id of your Android device. If no device listed, try the following:

• Reconnect USB cable.
• Toggle USB Debugging option off and on again.
• Run commands adb kill-server and then adb start-server.

I’ve already received multiple emails from people who are excited for iOS 4’s multitasking because they can’t wait for this to finally stop being an issue, because they think Instapaper will be able to download articles periodically in the background.

It’s painful to respond, crushing their hopes, to tell them that the iOS multitasking system doesn’t allow me to do that.

By naming these features “multitasking”, Apple has set customers’ expectations to include what apps can do in a traditional computer multitasking environment.

It’s going to mislead people into expecting such behavior from apps, but we can’t actually deliver most of it.

Some people will notice that no apps can do these things and properly focus their disappointment on Apple. But many others will only notice the shortcomings in one particular app that they need to do the “impossible” and blame that application, leading to dissatisfaction and negative thoughts about the app.

As long as iOS “multitasking” can do much less than traditional multitasking — which will probably always be the case — this is going to be an issue.

www.marco.org