I have a game and it runs well on Android through an application called C4Droid (If you don't know about C4Droid, just google it). It is written in C++ and only uses SDL2.
It runs on portrait and so, when I tilt the device with auto-rotation turned on, it gets landscape.
Now, what I wanted is to do something that avoids it to get landscape even when auto-rotation is turned on. Answer please?
Set orientation in Manifist file like this android:screenOrientation
<activity
android:name="com.androidgames.mreater.MrEaterGame"
android:label="Mr. Eater"
android:screenOrientation="portrait"
android:configChanges="keyboard|keyboardHidden|orientation|screenSize">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
No, there is no way to do this in SDL2 only (you can in iOS, but for some reason they made it different in Android). wadali's answer is best, here are some ways you can use it in your build environment:
Use a different build environment. If you build the APK on a desktop machine you can control the contents of the AndroidManifest.xml file. If you really want to do it on your phone, there are other C/C++ compilers for Android. The part you lose is C4Droid's ease of use - you will need to learn how to build the APK yourself.
Build it using C4Droid as usual, and then use an APK editor to extract, edit, and repackage AndroidManifest.xml. If you're comfortable copying the APK to a desktop machine you can use apktool to unpack the APK, edit the file you need, then repack it again (note: you will need to re-sign the APK after doing this before it can be used); otherwise, there seem to be a few APK editor utilities available for Android, too.
There are Android APIs for controlling the orientation, but you can't access them from within SDL2. SDL2 creates its own Activity and doesn't have any means of either extending it or letting you provide your own activity, so you cannot expose additional Android API calls to your own code.
Do you know about SDL_HINT_ORIENTATIONS?
https://wiki.libsdl.org/SDL_HINT_ORIENTATIONS
even if SDL docs claim they are for iOS they seem to work fine in Android.
SDL_SetHint(SDL_HINT_ORIENTATIONS, "Portrait");
Related
Currently I'm using twilio to make calls in android in my application but they don't support arm64 phones yet, my application keeps crashing as it doesn't find the appropriate libtwilio-native.so file.
Is there a way to disable this service only for an architecture? Is there a way to disable the service by default and enable it in runtime?
Additional info:
My manifest.xml file has this:
<service
android:name="com.twilio.client.TwilioClientService"
android:exported="false" />
The bools.xml trick doesn't work for me as arm64 phones and others phones can have the same android version.
Is there a way to disable the service by default and enable it in runtime?
Add android:enabled="false" to the <service> in the manifest. Then, at runtime, you can use PackageManager and the awkwardly-named setComponentEnabledSetting() method to enable it, if desired.
The bools.xml trick doesn't work for me as arm64 phones and others phones can have the same android version.
True, though if you are using product flavors in Android Studio for handling your CPU architecture splits, you should be able to use resConfig in the product flavor definitions in Gradle in lieu of the actual bools.xml files to define the boolean resource, and use that in android:enabled. Note that I have not tried this, YMMV, do not taunt Happy Fun Ball, etc.
When I am debugging my Android App, I see multiple apps of it installed on my device, each one seems to be of an holder version. This is really annoying because most are bugged and crash on launch. Anyway I can have Android studio just install the current version.
I've tried to uninstall all the app (uninstalling one uninstalls them all) and re-launching it and It adds them back. I am debugging, not building APK's.
Thank you.
Try deleting the old not working project folders.
Are you accidentally building and deploying multiple flavours? How does your modules .gradle file look like?
Edit: you might want to check this: https://stackoverflow.com/a/27633032/3540885 (Have you set up more than one activity to be launched at start?)
I believe there could be various reasons for multiple installation of app during debug. I also faced similar issue once for one of my app and I after a thorough analysis I found AndroidManifest.xml was the culprit, though it was my mistake as at some point while adding and testing multiple activities I defined two of the activities as launcher activities and hence it was creating two instances of the app when I was debugging.
Check if in your case too, you have defined multiple activities as launcher activities.
Following code part should only exist for your actual launcher activity which you want to launch when you app starts.
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
I'm developing a project that uses a Flash video within a webview. I solved all my problems regarding to code, but only worked below Honeycomb.
Reading this I found out how to solve the problems for Android 3.0 and later (including ICS), but now it's the big question... If I make my project compatible with ICS I've got to use the directive, but then I wouldn't run on Gingerbread.
To provide some more info... the problematic piece of code is this one:
android:hardwareAccelerated="true"
which is a property that was included in Android 3.0.
So, is there anything I can do to avoid building two different apks (somehitng like a pre-HoneyComb apk and post-HoneyComb apk)?
This is a piece of my Android manifest:
<application android:label="#string/app_name"
android:icon="#drawable/elabora"
android:theme="#android:style/Theme.NoTitleBar">
<activity android:name="es.fundacionvodafone.elabora.android.controlador.InicioElaboraTest"
android:label="#string/app_name"
android:noHistory="true">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity android:name="es.fundacionvodafone.elabora.android.controlador.InicioElabora"
android:configChanges="orientation|keyboardHidden"
android:label="#string/app_name"
android:hardwareAccelerated="true">
<!--
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
-->
</activity>
Thanks in advance.
Update:
I was already using what Mike explained, it's to say, defining minSdk and targetSdk properly, but I was confused by the following fact. With such a project configuration, when you run the project in eclipse, it prompts the following window:
The red cross means that the project targetSdk level is above the device API level. So I thought it was just not working in this device, but the thing is you can actually run it, and works as expected.
The comment posted by the OP below his question (basically stating that the targetSDK doesn't affect the compiling of an app) is entirely wrong! Sorry to be blunt.
In short, here is the purpose to declaring a different targetSDK from the minSDK: It means you are using features from a higher level SDK than your minimum, but you have ensured backwards compatibility. In other words, imagine that you want to use a feature that was only recently introduced, but that isn't critical to your application. You would then set the targetSDK to the version where this new feature was introduced and the minimum to something lower so that everyone could still use your app.
To give an example, let's say you're writing an app that makes extensive use of gesture detection. However, every command that can be recognised by a gesture can also be done by a button or from the menu. In this case, gestures are a 'cool extra' but aren't required. Therefore you would set the target sdk to 7 ("Eclair" when the GestureDetection library was introduced), and the minimumSDK to level 3 ("Cupcake") so that even people with really old phones could use your app. All you'd have to do is make sure that your app checked the version of Android it was running on before trying to use the gesture library, to avoid trying to use it if it didn't exist. (Admittedly this is a dated example since hardly anyone still has a v1.5 phone, but there was a time when maintaining compatibility with v1.5 was really important.)
To give another example, you could use this if you wanted to use a feature from Gingerbread or Honeycomb. Some people will get the updates soon, but many others, particularly with older hardware, might stay stuck with Eclair until they buy a new device. This would let you use some of the cool new features, but without excluding part of your possible market.
There is a really good article from the Android developer's blog about how to use this feature, and in particular, how to design the "check the feature exists before using it" code I mentioned above.
To the OP: I've written this mainly for the benefit of anyone who happens to stumble upon this question in the future.
I have similar problem with versioning the android manifest. For older phones I want to have widgets in a few predefined sizes, for newer phones that support resizing I want to have a single resizeable widget. Could not find yet a way to do it. Possibly this is why Google came with multiple APK support.
The Adam's Powell article mentioned above does not address this kind of versioning. (great article BTW).
Edit: got a solution. The widgets definition in the android manifest have a boolean 'enabled' attibute that can be set from boolean resource values. The resource values can have per version values using the standard version qualified resource directory names. Problem solved.
I have developed two small applications for Android using Eclipse. Then i ran them both on the phone by right-clicking on the project and "run as android application", and they were successfully tested. However, when i try to install their .apk files, one of them appears in the list, while the other does not appear. I checked the application manager and it shows that the application is saved.
I tried to find it using the "search" in the phone, it can find all saved .apk except this one.
Pls do you have any idea where did i go wrong especially that it seems saved, and only this application does not appear in the phone although the application manager says it is installed.
Found out why this was happening. You need this in your AndroidManifest as a part of your main activity.
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
My mistake was that I used <action android:name="android.intent.category.LAUNCHER"/> instead of <category android:name="android.intent.category.LAUNCHER"/>. Without the category.LAUNCHER, you're not telling it to list the software in the application launcher, so it becomes invisible.
You may need to enable third party apps on your phone since it is not able to find the one you created.
(Applications >> Enable Unknown sources)
Also you may want to use an APK installer(search) App like App Installer to easily find your own APKs and install them.
And as always uninstall and give it another go, as mentioned above it has happened to everyone it seems.
Your way of description is quiet messy. By phone do you mean the emulator? If it cannot find the .apk and it doesn't appear in the project folder, then clean the project (Project menu) or restart Eclipse. This usually solves the problem. Idk why this is happening so often.
I have an app, let us call it 'com.company.foo', with a main Activity 'FooBar'. In my AndroidManifest.xml, I have
<application android:label="#string/app_name"
android:icon="#drawable/icon"
android:theme="#android:style/Theme.NoTitleBar.Fullscreen" >
<activity android:name="FooBar"
android:label="#string/app_name"
android:configChanges="keyboardHidden|orientation" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
...
</application>
(where the dots contain other activities inside my app). In this form, it works fine on my HTC desire and on the emulator. However, a (very) small number of people who downloaded the app from the market report a crash with
java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{com.company.foo/com.company.foo.FooBar}: java.lang.ClassNotFoundException: com.company.foo.FooBar in loader dalvik.system.PathClassLoader[/mnt/asec/com.company.foo-1/pkg.apk]
Someone suggested to replace the android:name="FooBar" with android:name=".FooBar", which again works fine on my phone and the emulator, but fails on some other devices. If I leave this attribute out altogether it will not let me install at all.
Any ideas?
I have an app published on Android Market. And sometimes I receive similar crash reports. Seems that's not your fault. This can be reproduced if your app is installed on SD card. Eject this card without unmounting it and run your app.
Additional information can be found here.
The code that you have shown is fine, can't see anything wrong with it - so what else have you looked at?
Have you checked the SDK level against the android release on teh phones that have failed? Any chance of some incompatability there?
Instantiating the activity I have found to my cost is a non-trivial matter and there are so many things to go wrong - you will have to go back over all your support files and make sure that they are clean but think about incompatabilities.
You have not said what imports are involved - have you tried cutting down your app to the bare minimum and see does it still cause problems with those small number of rogue phone - maybe you dont have access to the phones?
Try posting the phone makes/models that are causing problems, also where to access your app and there might be someone out here with the same make/model who would be willing to do some testing for you
Sorry I can't be more help,
Good Luck!!
Oliver