I'm trying to make some of my applications available on Android 4.0 (Ice Cream Sandwich) devices. It would be helpful to know the different things to look for, as sort of a checklist.
What are the generic steps necessary to make an application available and functional on an Ice Cream Sandwich device? I'm not looking for every single potential API change to make, but any detail would be appreciated.
One thing I have encountered relating to usability is that if you have a fullscreen activity, to allow some way to exit it or go back since phones might not have hardware keys to send the back event. Basically, never assume that the user has hardware keys available.
Google also recently released a design guide for ICS available at http://developer.android.com/design/index.html
Well, as Blundell said, it should work without any problems. I have however, found one quirk while running ICS in the emulator with my apps (maybe this applied to Honeycomb as well, no idea).
Here it is - if you have an app widget, and you don't provide the android:previewImage attribute in the appwidget-provider configuration, your widget will not be visible in the "Widgets" tab. You can use an app that comes with the ICS emulator (Widget Preview) to generate this preview image.
Related
Background
I have a live wallpaper that uses the relatively new API (from Android 8.1 - API 26) to request the OS to use customized colors:
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine.html#notifyColorsChanged()
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine#onComputeColors()
The problem
On Android 8.1 and even on Android P DP1, all worked fine with these functions, as they did what normal wallpaper do with the colors, affecting the notification drawer if the color that was chosen is dark enough. Here's a comparison between choosing a non-dark color and choosing a dark color background:
Thing is, on Android P beta (DP2), even though this function get called, it doesn't do anything, ever.
To test it on your own, you can try the full project I've published here.
What I've found
I thought that maybe the API has changed, so I've tried to find which functions are available, but I couldn't see anything that's new.
I've tried to use various ways to return the customized colors:
a. WallpaperColors(Color.valueOf(0xff000000.toInt()), Color.valueOf(0xff000000.toInt()), Color.valueOf(0xff000000.toInt()))
b. WallpaperColors.fromDrawable(ColorDrawable(0xff000000.toInt()))
c. WallpaperColors.fromDrawable(BitmapDrawable(completelyBlackBitmap))
d. WallpaperColors.fromBitmap(completelyBlackBitmap)
Sadly none worked (fromBitmap is the one that works well on Android 8.1).
Seeing this, I've re-checked that my code is ok, and noticed that the built in live wallpaper works fine, and that selecting a solid black wallpaper (instead of live wallpaper) also affected the UI of the OS.
Seeing that it works with built in apps, I've reported to Google about this issue, only to find out that they don't understand what I'm talking about, and each time I've tried to tell them they've misunderstood it differently:
https://issuetracker.google.com/issues/79404938
https://issuetracker.google.com/issues/79665215
https://issuetracker.google.com/issues/80029770
I wanted to make sure it's not an issue with just my app, but with others too, so I've tested Muzei live wallpaper app, which is actually made by one of Google's own developers. The issue indeed occurs there too, while working fine on Android 8.1.
I was just curious, and wanted to check if the issue could occur if I've moved Muzei to be a system app, but after doing so, I've seen the issue still exists.
The questions
How come it doesn't work anymore?
Is there a workaround/fix for this?
Why does it work fine for built in apps and for normal wallpapers, but not for third party apps? I don't think their code is any difference.
OK, Google confirmed it's a bug, which will be fixed on later version:
The development team has fixed the issue that you have reported and it
will be available in a future build.
And, it works fine now on DP4 (beta 3) of Android P.
In Google play (app market), if an application is not compatible to your device (for some reason, say small screen size, etc). Then it is not even shown in the list.
Now, as an app developer I never want to unintentionally add a limitation in my app that forbids it from a range of devices.
So, while developing how can I make sure that the application will be able to run on atleast the type of devices that I intend.
Also, right now I'm developing an app & testing it in on my phone with version 2.3.5. And every now & then Google changes some method names & flags.
For newer android releases, I CAN test it on emulator, but testing it on phone/tabs/etc. is a different thing.
Please suggest.
how can I make sure that the application will be able to run on atleast the type of devices that I intend.
In manifest file you can mention, which type of device you want to run your app. And for testing you can create emulators for different devices to test your app. Try to make app UI such that it runs on all devices.
Google changes some method names & flags
Whenever Android changes any thing it will always be upward compatible means if you have made app for 2.2 it will run on 2.2 and above (screen size or resolution is other thing)
Regarding UI see my answer here
Layout for 720*1280 devices
By default apps will be available to as wide a range of users as possible.
There are certain limitations you can define in your manifest file, such as not being available on small screen sizes, but they are at your discretion.
The only limitation Google imposes on you is that any user who has a lower Android version than your minimum SDK version cannot see your app. To get around this, you can either design the app for lower SDK versions (I believe building for 2.2 and up gives you access to about 95% of the user base) or maintain multiple versions of the APK.
Read this. It will really help. Next Eclipse will help you a lot, firstly you can define what you wish to support (screen sizes and hardware requirements or even if they're not necessary but may be used) in the manifest. You can run a version check and implement APIs dependent on which version of Android you're running on. That's personally what I do, I check the API level and if it's greater than or equal to the API I wish to run I run it, otherwise I attempt to find compatible code (often using the compatibility library) or alternatively drop support for that feature, for example JellyBean notifications there's not really any work around for expanded notifications but I can use the NotifcationCompat builder.
I have a widget that makes use of a new feature that, according to the infinite wisdom of the intarwebs, is stock in Android 4.0 (Ice Cream Sandwich). Conveniently, my phone is just that.
This widget inverts the screen colors for the phone. Not just an app; the screen in its entirety.
I started playing around with an amazing app called Tasker the other day that can do some crazy-powerful things; including run scripts, send commands to the phone, etc.
I'm trying to figure out where in the world this inversion lives so I can tap into it myself via Tasker, but I'm falling short everywhere. The Android API documentation is Greek to me, and Google seems to only ever want to point me to people talking about how great the feature is.
Any ideas as to where I can find this feature/function/action/whatever in a programmatic sense?
Thanks much in advance! Any help will be most appreciated.
I've searched and the only thing I found is when it's available on custom roms/kernels.
I don't think it's available for stock roms.
I'm spending considerable time in making my UI to work with keyboard input only. But in the end I'm not sure whether I can rely on the assumption that Android devices all have touch screens.
Is there a way to determine if an Android device has a touch screen?
You should research the existing devices and read the Android Compatibility Definition Document (CDD) and decide for yourself.
I have spent some considerable time trying to figure out this problem for myself. The posters above are correct that Android already powers some non-touch devices and will power Google TV in the near future, but as it currently stands, the CDD specifically requires that ALL Android devices MUST have a touchscreen.
Basically, the Android Compatibility program was created to hedge against the sort of fragmentation issues you're worrying about now. It lists a bunch of requirements, and if a device does not meet those requirements, it does not get access to Android Market. These requirements include a touchscreen, wireless communication, bluetooth, a camera, and much more.
If you research those tablets and netbooks, you will find that not a single one carries the Android Market. Augen recently tried to pull a fast one with their new GENTOUCH 78 tablet, but had to rescind their claims that the tablet would carry Android Market after being shot down by the Android Compatibility Team.
So, if you are only distributing your app through Android Market, you have nothing to worry about until Google changes the CDD. But if you'd like to offer your app on other app stores or as a direct download, then you'll have to worry about your key mode navigation issues.
If it's any consolation, I have found that many, many apps have the exact same problem; they are impossible to use without a touchscreen. Many of them also have serious issues with focus and the soft keyboard. Sometimes the keyboard stays up when it should be hidden. Sometimes you can't get the keyboard to pop up no matter how many times you click on an EditText. IMO, the Android framework does not handle these things all that well.
Given all that, it will certainly be interesting to see how Google TV fits into all this. Will they update the CDD to be compatible with their set-top boxes? Will they use a different SDK and CDD for Google TV implementations? Will they ignore the Compatibility Program altogether when it comes to Google TV? Your guess is as good as mine.
Update:
It seems that someone at Google has finally come forward and admitted that Android is not ready to run on a tablet:
http://phandroid.com/2010/09/10/shocker-google-says-android-not-meant-for-tablets-in-its-current-state/
To me, this says that Google was not prepared for the accelerated adoption of the Android OS and has not adequately roadmapped the future of the platform. Supporting screens larger than 480x800 is barely possible, and Samsung was only able to do it by working closely with Google on the Galaxy Tab. So I'm not so sure we need to worry about non-touchscreen devices in the near future. They'll be here eventually, I'm sure, but when they do arrive we may see a separate app market just for those, or some altered filtering scheme on the existing market, a new CDD, who knows.
To me, this says that Google is still playing it by ear, and we'll just have to do the same.
All the phones so far have touch screens, but there is no promise that they must.
However there are lots of netbooks, notebooks, and soon to be TVs that have no touch screen.
However these devices have mice. From what I've seen, the mouse input gets pumped through the touch system so MouseDown is ACTION_DOWN, etc... (Don't know about right click though)
Are you targetting just the phones? Android is appearing on many devices including TV's I've no idea if new libs will be released to isolate parts of the devices from each other, but if you want a broader audience I'd suggest keeping the keyboard input available if you are
Google TV (GTV) is the most popular Android notouch device (as of the time this answer is composed). However, there are several devices that will call for notouch renderings if you have "notouch" resources (e.g. a directory like res/layout-notouch/ )
To accommodate notouch devices, made sure that focus will cause a visual selection indicator, and (for GTV) that keystroke listeners are in place for the directional-pad center button. Using default widgets and themes will often accomplish much of this automatically. If you make your own buttons, you need background 9-patches for focused and focused+pressed.
Running on a GTV is a good test environment to make sure that notouch works well, and GTV has an emulator now, though it runs only on Linux/x86.
Do you have any idea what's the starting point to develop an UI for Android OS, similar with HTC SenseUI ?
Can I create that on top of Android or I need to get the Android source code ?
Thank you.
Florin Matincă
You'd need to modify the Android OS to some extent, but since Android is open source, that's not a problem.
The problem is getting it installed on phones - if you've noticed, the only companies that have custom UIs are also phone manufacturers, so they can just ship their phones with it installed. Also, if a new version of Android comes out, you'd need to get the new source, and modify most of it again.
Distribution would be a serious problem...
HTC Sense consist of a variety of functions.
Some like the Lock Screen can be implemented as normal programs. The start screen for programs can as well.
The systems setting for example can't be easily replaced without going into the android source code.
I have to disagree with xil3, there are some realy popular home screen replacements out there not restricted to a certain brand.
ADW.Launcher
LauncherPro
HelixLauncher
HelixLauncher2
All four are available on market place and therefor the distribution is simple.
HelixLauncher (and 2) are based on the Launcher from android itself, for which the sources are available as a git repository. This means you could use these sources to start your own Home Screen replacement.
So have fun!