I have a question whether it is possible to check if the battery level is currently displayed on screen on Android device. Is there a property in SDK that allows to get this information?
Not a standard one, no. It's up to the OEM how they want to display it, which means they don't have to use the AOSP version.
Anything near-AOSP is probably using status_bar_show_battery_percent in Settings$System.
Samsung uses display_battery_percentage in Settings$System.
LG seems to use power_save_battery_indicator in Settings$System.
You can use Settings.System.getInt() to retrieve the value.
Related
So here's the scenario: we have an old app on the Play Store that was published before there were any tablets (it runs on tablets using the phone interface.) We want to release an update to that app (because it has >150K users) instead of a new app but because the design for the phone UI won't be ready in time for our deadline we want to release an update that targets only tablets for now while the existing users continue to use the old phone-only app. Later, when the design and implementation of the phone UI is complete, we want to release another update that adds support for phones.
Ideally what should happen is if a user is using the old app on a phone, they will not get the first upgrade notification but a user running it on a tablet will get the update notification (and a new user installing it for the first time will get the the old apk if, for example, they're running a Gingerbread phone while a user using, say, a Nexus 7 will get the new apk.) Eventually, all users will get the update notification to the second release no matter what Android version/device type they are running.
If we do this, what will the experience be for the current users that are using the old version on phones? Will they be prompted to upgrade to an app version they cannot run or will they get no update notification at all? Later, when we release the second upgrade that does support phones will they then get the update notification?
To make your app look great on tablets, just add specialized layout types, just like
layout-large or layout-sw600dp. Then copy your existing layout-xml files from your layout folder to these and modify them as required.
I suggest reading Supporting Different Screen Sizes.
This way, you add tablet-optimization without throwing away phone compatibility.
I'm not quite sure what you mean by having an update only available to a certain device. Tablets and phones work quite differently and the Google Play market is capable of differentiating what will run on the user's current device and what won't.
Like the previous answer you WILL be required to construct different layouts specifically for tablets.
However if you only want an update to tablets to take place on tablets - You need to get as much information about the screen size, density, device version and maybe even the current users android OS version to really help you narrow down whether the current device is a tablet or large screen device or not.
For example:
Get screen dimensions in pixels
shows you how to get screen dimensions.
How can I check the system version of Android? Gives you more information about the current android version.
getting the screen density programmatically in android?
will allow you to find out the screen density of the current screen.
Using all of the above, or some similar combination, you can determine if the user is running your app on the tablet, if they are, provide them with an update, if not, the app continues with its regular layouts as normal.
I'm not quite sure if this is the answer you were looking for, but I hope it helps.
Take care
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.
My app is set to run on minSdk = 5, but the vast majority of users are using SDK 8 (FroYo) and higher. I want to be able to use the android:configChanges="uiMode" for my main activity, but I can't do it because that mode wasn't introduced until SDK level 8. So, I was hoping that I could do it at runtime -- check which SDK level is running on the device, and then use reflection to add that parameter.
Is that possible?
EDIT:
The problem is that whenever a user's phone is connected to the dock, my app gets terminated, and then re-created. I'm trying to avoid that by including the android:configChanges="uiMode".
After much poring through the Android Reference, there is very little you can change from the manifest at runtime. This is due to security because through the PackageManager, one can gain very specific information about any application on the device. While it is easy to enable/disable a given Component, in most other circumstances, you can only read manifest information... not write it.
Alternatives
You could potentially make a separate APK with API Level 8 support.
You could manually check for configuration state and run your code when it changes. The object reference for configuration is here.
Edit: (new info)
While you cannot change the configChanges, I found this question that is closely related to yours. It turns out that you might not have to. It implies that you can use Android's backward compatibility mode when supporting new configChanges. In case the link above is broken, here is the URL: https://stackoverflow.com/a/7893148/501932
To put this to use for you, it suggests setting a new targetSdk while maintaining your original minimumSdk. It also requires that you have the updated SDK, itself. Apparently, this was a huge deal for users that utilized that AdMob API.
App Configuration for forward compatibility
The answer I provided is a simple what to do, but not much or the why, this should update the answer as well as act as apology to the SO community for sparring with the poster, which was pointless and added nothing to the conversation.
I think it’s an important point to expand upon this issue since these kind of questions come up a lot and developers in a hurry (aren’t we all) and we have a tendency to cut/copy/paste and worry about the why of it later which mostly works out but occasionally just adds to the problems.
If you understand how the android runtime actually works you can often solve these types of problems by applying a simple pattern of best practices by using the block in your manifest, and making good use of the Build Target when compiling your app, followed by some simple testing at the compile and run time levels.
Manifest
minSdkVersion =
Pretty straight forward it’s the lowest build target you will support on a specific device. If you don’t set this it defaults to 1.
The only caveat here is that if your Build Target is higher than your minSdkVersion than you can potentially call API’s that don’t exist on the device, more on that under Build Target.
This will filter you app from on the various market/play repositories for devices that have lower OS support.
How you make this determination is up to you, if you must have your app run on every device ok, but take a look at Platform Distribution to make an informed decision.
If you are willing to bypass 0.9% of the market then target 2.1 which seems reasonable but that’s a decision for a developer/company to make, if you can bypass 25% of the market then go with 2.3 which has significant advantages but is a bit hard to swallow for most general purpose app’s.
The linked chart is updated from time to time.
targetSdk =
If you don’t apply this value then it defaults to whatever minSdkVersion you set. This means that when you run on a device with higher OS support certain new looks and or behaviors that are implemented will be bypassed in favor of the older way of doing things.
For instance if you apply 10 to the minSdkVersion and then your app runs on a device with gingerbread (11) it will not attempt to use the holo theme, or disable screen compatibility mode. In general this might give your app a “Dated” look and feel.
If on the other hand you set this to something higher, like 11, then the system will use the native look and feel of the OS up to that value you set. Best practices is to set this as high as possible and then to test on the higher level device in the emulator to make sure this is acceptable.
Some of the changes that effect compatibility behavior between OS jumps are documented here Differences between OS's
This will not stop you from running on earlier devices, or effect those earlier devices look or feel (see ActionBarSherlock and the Android Support Library if that’s your goal)
maxSdkVersion =
In general this does just what it says it does, it restricts availability and deployment of your application on devices that have a higher OS level from Google market/play.
On android 2.0- it will also refuse to install the apk, and will even remove your app if a device is updated to a level higher than this setting, 2.0.1+ removed the second part of this behavior but the markets will still filter based on it.
In general there is no reason to usually set this value, so leave it blank.
Build Target
When you set a build target in eclipse (or otherwise) you are telling the complier which API’s, constants, etc. should be VISIBLE to your application.
In general it adds a jar file that has all of these definitions/declarations but of course not the actual classes/methods so that you can compile your application for any target OS you desire.
When your app runs on a device it links to the actual android OS/support jar file(s) (or blows chunks if they are not there)
If you select a build target higher than you are willing to support then bad things can of course happen when you try and call method that does not exist, or even a class that does not exist on the Older OS.
If on the other hand you are willing to carefully manage and test this then you can obtain forward compatibility in the sense that you can use the new API’s on newer devices so long as you don’t attempt to do so on earlier devices.
Best Practices – Short Version
This is what the poster is trying to accomplish and if best practices are followed it works out well, these are in general
minSdkVersion = lowest general API you will support
targetSdkVersion = highest behavioral model you are willing to allow
maxSdkVersion = leave it blank
Build Target = generally as high as is currently supported
The real caveat is that you have to avoid API mismatches between older and newer versions, and make sure your app looks and acts ok on the higher version.
In general methods/classes that are higher than your minimum targeted OS should be used sparingly and tested at both the compile and runtime level since it requires some effort to use them safely.
Here is how I go about it
minSdkVersion = 7 ( I can live with a 0.9% clip again your choice )
targetSdkVersion =15 ( highest as of this writing )
maxSdkVersion = ( blank )
Build Target = 15
When developing I never use an API not available on 7 unless I have a real need to do that, in the posters question he could have used a broadcast received to get similar functionality back to 6/7 (2.0/2.1) but he states he needs API 3 support so he has to support forward compatibility.
One tool you can use, and most don’t just to keep things straight is to set the API level on the developer.android.com website to your minimum SDK level, this gives you a heads up when developing that you will have to support forward compatibility.
It will still show the other API calls but it will gray them out telling you that extra effort will be needed to support them
If you do need to use a newer API you will need to do an if then else so that they are only called on the newer device, this will allow you to support the new functionality without getting a force close on older devices.
So in general if you support higher API levels those calls should be wrapped with something like this (note the .SDK_INT is a since API 4 test)
If ( Build.VERSION.SDK_INT >= API11_SUPPORT ) {
switch(newConfig.uiMode) {
case ...
}
Testing – manual method (CI integration methods are left up to the reader ;-)
Compile with the build target set to the minSdkVersion – this will give you compile errors on any newer API’s that you are using, check them out and if you handled them great, if not now is the time.
For every issue I see at step 1 I add two items to the code (manifests/xml )
// TODO Compatibility xxx
if (DEBUG) Log.i(“MyApp”,” Compatibility xxx”);
I can then use the eclipse TODO pane to check off compatibility issues before ship and test them against the lowest/highest and any significant in between OS versions
Test on minSDKVersion device/emulator, this is a bit tricky if you are not doing comprehensive testing, in general use step 1 above to make sure I exercise those blocks of code
Test on Build Target device/emulator to make sure look and feel work as expected
If you think it’s a bit of work it is, but when you need it you should do it right and make sure your app does not break.
Hopefully this is useful to someone trying to figure out similar situations, below was my second response to the poster, Cheers.
UPDATE:
I still have no idea what the author is asking, but if he is asking if there is a way to detect the configuration changes in regard to uiMode (docking stuff) on 7 and below using the onConfigurationChanged handler then no since that was only introduced in API 8.
There is a broadcast event sent in API 2.0+ systems, but apparently that has some issues and does not seem to be completely reliable
If he is asking if there is a way to support it on devices that are API 8 and above via the onConfigurationChanged handler by setting the flag in manifest for the activity then of course there is
Of course he may be asking about something totally different, it's hard to tell exactly what he is looking to do given his post none the less in the spirit of cooperation:
Select an API from project properties that is >= 8, best practices is to use the highest API available when you create your app for just this reason BUT care must be taken not to call any API's that are not available on the device.
Then in the manifest use (duh)
<activity
android:name=".myActivity"
android:configChanges="uiMode|orientation|keyboardHidden"
This compiles fine (and that is really the only issue and why you need to set a higher api in the eclipse project properties) this will run fine on 7 and below it just wont trigger any events because of course API 7 and below devices won't recognize the uiMode flag (duh)
API 8 and above of course will recognize it and send the proper event so on api 7 the log will be written, on api 8+ it will (if docked etc) of course the calls that are made if it does happen will most likely be 8+ related so you would need a OS check block before calling them.
#Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
Log.i("myActivity","uiMode="+newConfig.uiMode);
}
If you compile and run on a 7 API emulator and fire a dock broadcast nothing happens, change to a 8 API emulator and it does
adb shell am broadcast -a android.intent.action.DOCK_EVENT --ei android.intent.extra.DOCK_STATE 2
If I want a certain application to be available for certain devices only or for tablets only, is there any way to make limitations by device (like I can limit the min/max Android OS version)?
I say it is impossible. Do you agree?
I understand that you are trying to limit the devices that can see the application in the Market but, like you, I do not think that is possible. You can, however, limit it within the app using details from and Build class. Build.PRODUCT looks like it would fit your needs - if the phone that has the app installed in not in a pre-set list of "products", tell the user that they have the wrong version and exit.
A similar idea for tablets is to check the screen size - if they are under a certain threshold, then display that same message.
It is possible, starting in june this year. Please take a look at this Google I/O session:
http://youtu.be/GxU8N21wfrM
Is it possible to enumerate all the displays supported by an Android device? The APIs currently support getting the default display, but don't appear to support getting any other displays.
I did not find any official API for multiple device displays, even if it looks like it will support it in the future.
No, it is not, I think you're confused about what getDefaultDisplay does, it gets the display of the current device, not the global Android default, which does not exist! For information about screen sizes/densities look at the documentation.