I created an app with minimum SDK 7 in order to get maximum compatibility with circulating devices. On Android phones (GB2.3), pressimng Menu button pops up a menu strip on the bottom of the screen, and that is correct.
However on HC3.2 tablets, where no menu hardware key is present, I expected a soft-menu key on the bottom of the screen, but it didn't appear, so I can't open my menu.
I don't know where to investigate and which portion of my code to share, so could you please show me where do I have to look for menu softbutton?
After reading that menus are deprecated in most recent Android versions, I don't know if ICS4 has a soft-menu button or not. I never tested my app on such a device. Can you give me advices?
Thanks
The link you provide tells you how to correctly provide action bars in your app so that the presence or otherwise of a physical menu button is irrelevant, so that's a good start.
Now, you need to combine that with a little runtime detection of the SDK version (just check the Build.VERSION.SDK_INT constant for Android 1.5 or above), along with some appropriate reflection to enable the same APK to run on any Android version starting with your minSDK version.
Related
Quick question, Android related..
How do I display a working "THREE VERTICAL-DOTS" floating action button, to trigger same functionality as Android menu button that worked on Kitkat (Android-4), and all previous Android versions?
Details:
I have an Android app that uses Java Native Interface. It worked fine in Kitkat (Android 4.x series), but in Android 5.x, the menu-options button (three vertical dots) no longer responds. Originally, in Kitkat (Android 4.x), the standard Android menu button brought up the applications configuration menus. Now, in Android-5, the Menu button has been replaced with a "Recent Apps" button (this was a very poor design change - probably the worst basic re-design of a working interface I have seen in 30 years... ). Is there an easy way to use a "floating action button" or something like that, to restore functionality of the standard Android "Menu" button?
On Samsung tablets, one can tweak: "Settings / Accessibility / Dexterity and interaction / Assistant menu " to "On", and then a floating-action-button appears, which then has the three vertical-dots as one of it's optional push-buttons, if invoked. Pressing that three vertical-dots button (on the Samsung FAB (floating-action-button)), triggers the old Kitkat/Android4 menu, and at least Samsung users can alter set my app config parameters.
In my app's AndroidManifest.xml file, I have minSdkVersion="8" and the targetSDKVersion="8". I have tried setting the targetSDKVersion to higher levels, which results in a non-functional floating action button, showing three vertical dots, appearing on the screen.
There must be an obvious way to fix this damage that the Android "Material Girl Design" people did to Android Kitkat(and previous Android vers.) Android Menu Button. I've detailed a work-around for my user-base at this point, and released an new app version which offers details on the work-around - at least for Samsung phone and tablet users, but an in-app button really should just appear to allow the main app configuration menu to be triggered.
I have looked at this:
http://developer.android.com/training/appbar/setting-up.html#utility
Don't want an "Action Bar". My app is a DOS-emulator, and needs all the screen space.
I have also reviewed:
Android Options Menu in Fragment
This gets closer, but rather than trial-and-error, I would like to just jump to the solution, if possible. There must be some code or a feature selection that just fixes the little action button that appears (but does not work), when I set the targetSDKVersion="12" (or higher values), in the AndroidManifest.xml file.
My app uses SDL (Simple DirectMedia Layer) vers. 1.2 and 1.3 to control and draw the screen.
I will post the answer here when I find it. I know it is possible, because Samsung is already doing this, within its "Accessibility/ Dexterity.. /Assistant Menu" feature.
This kind of behaviour appears on devices that have a hardware settings button (e.g. Samsung Galaxy S3). Apps like Hangouts or Slack use both an overflow menu and the menu that appears when pressing the hardware settings button.
Using an overflow button to show exactly the same options as the hardware settings button menu seems redundant to me. It also seems like it stands against best practices. Because such behaviour appears in many popular apps, I think this might confuse the regular user a little bit.
Is this to make the user's transition to newer versions of the Android platform easier?
Is it recommended to implement the options menu this way for such devices?
I suppose so it depends. Even an Samsung G5 or G6 have a hardware menu. Press the multi tasking window for a long time. It does the same as pressing an overflow button. This is so that the uses of older versions of Android can use there accustomed way of using the menu button. This simply provides your app with a richer User experience.
Especially value of minimum SDK version is very low it is recommended to use this to provide a richer User experience to your application. It is your wish as to how the app is supposed to workm
I designed an app on the phone and am moving it to tablet. Testing on 3.2, a Samsung something-or-other. The legacy menu doesn't fill the screen using existing resources...
So, notwithstanding this, how can I make my menu fill up the horizontal space? (Besides playing tricks with wide images, if that would even work.) Again, I'm not interested (yet) in doing the action bar overflow thing.
This is not supported by the SDK. The layout of a menu is determined by the OS, occasionally modified by the device manufacturer. You, as an SDK app developer, do not have control over sizing, number of rows/columns, etc. In effect, the "menu" is an abstraction -- you simply indicate what items should be in there, and the visual representation of that is up to Android. That's why, for API Level 11+, there are zero code changes required to use an action bar, other than to have android:targetSdkVersion set to 11 or higher.
I have application which uses Sherlock ActionBar package.
The application uses platform-specific behavior for menu (so it's 3-dot icon in ActionBar on ICS and classic menu under HW button on pre-ICS)
I had recieved report from one user with HTC One X. It appears, that One X shows some "compatibility" bar with menu button on the bottom of screen, and there is also same button in ActionBar (where it's supposed to be).
I was not able to emulate this in AVD, and I have multiple reports that this issue is not present on Galaxy Nexus or Galaxy S (they show only the icon in ActionBar).
I have no idea where to look to resolve this or how to debug it, so any help or workaround will be appreciated.
Application is built against API14, with targetSdk="11"
You have a typo:
The android:targetSdkVersion in the manifest should be the solution - it's recommended by Google to always set it to the maximum available (currently it's 19).
Some websites do show that HTC shows the huge button on old apps, but not on new ones, as shown here, so if you think it's weird/ugly, simply set the target SDK. Also make sure it's updated in the project.properties file .
I am trying to get my app to be backward compatible so i need to show the menu button
since we used the menu button in our app on previous versions.
So I was reading and it says that if your target is 11 (3.0) than you don't get the menu button but it your target is 10 they you do.
But the issue is I am using fragments so my target has to be 11.
Any thoughts.
Ordinary options menus will appear regardless of Android version. If you have:
android:targetSdkVersion="11"
then the options menu will appear in the action bar on Android 3.0+ devices. All items in the options menu will be available when clicking the "overflow" button in the upper-right corner. Your options menu will appear normally on Android 1.x and 2.x devices, even if you have android:targetSdkVersion="11" in your <uses-sdk> manifest element.
If you overrode the MENU button to have other behavior, you will need to create some other trigger for that behavior for API Level 11 and higher. Overriding the MENU button was never a good idea to begin with, and as you can see, it is even less of a good idea now. I know of no way to get a MENU button on an Android 3.0 device if you have android:targetSdkVersion="11".
One thing that worked for me in order to get older Options Menu on Tablet devices was after I used the following:
minSdkVersion="11"
targetSdkVersion="10"
I think what helps over here is that I am stating to system that app has been tested against API 10 so I get older Options menu.
And because my app is meant for tablets only, keeping minSdkVersion to 11 also prevents it to be installed on the smaller devices. I know, I might still have to see the case of installation for smaller devices having ICS.