I have a Fullscreen Immersive ane for a flex mobile android application where I have to set -swf-version=28 to make it compile. Once I do this, the code for my peer2peer communication breaks.
NetConnection.Connect.Success fires then I set up a GroupSpecifier and NetGroup where NetGroup.Connect.Success also fires.
NetGroup.Neighbor.Connect is the event which isn't triggered anymore.
Two questions:
Why do I have to set the -swf-version manually to use the ane?
(included native extension 'com.mesmotronic.ane.fullscreen' includes a SWF version 28 which is greater than the version of the root SWF of this application: 14)
Why does the NetGroup break when I change the swf version?
Thanks in advance for any help
By forcing the newer SDK with the additional compiler argument I of course used a newer SDK. Using the same SDK for the Server Application did the trick. Messaging is working again.
Also I switched to Apache SDK so I don't need the additional argument anymore.
Related
I'm just wondering, if the latest Android SDK installed on a device contains code of all the previous versions as well?
So if I target API level 10 in my app and install it on a device with Lollipop, will it just take and use Gingerbread SDK exactly as it was 3 years ago?
Or is there just one codebase for all versions with a lot of checks and switches which is then run by some kind of compatibility mode picking the correct code and enabling methods of the version of SDK I target?
I read the article about android:targetSdkVersion specified in Manifest but still would like to know how this works internally.
Ok, I just surfed a bit around on the source code (which you can find here: https://github.com/android/platform_frameworks_base). I'm not an engineer of the Android framework, I was just curious about your question and here is what I found.
It does not contain all the different versions of source code. You can imagine that this would result in a nightmare if more and more versions become available. Foremost, you would have different (buggy) versions of the same method without fixing them just to keep them the same.
In the source code, you can find places like these: (see https://github.com/android/platform_frameworks_base/blob/59701b9ba5c453e327bc0e6873a9f6ff87a10391/core/java/com/android/internal/view/ActionBarPolicy.java#L55)
public boolean hasEmbeddedTabs() {
final int targetSdk = mContext.getApplicationInfo().targetSdkVersion;
if (targetSdk >= Build.VERSION_CODES.JELLY_BEAN) {
return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs);
}
// ...
return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs_pre_jb);
}
So the Android developers do the version check in the code where necessary. But these checks are not as necessary as you think (I guess). What's the reason for changing a method?
method is buggy: All they need to do is fix the bug. Tests will make sure that the general behavior of the method keeps the same
method is deprecated: The guys can not remove the method, all they can do is mark it as deprecated and hope for the best. Compilers will do the rest.
method behavior has to change: Well, I guess that is something they can not do easily. They can work around with version codes (which is pretty ugly and becomes a maintenance nightmare), or they just introduce a new API. That's the reason why you'll find a lot of APIs just doing the same
If you have write down a code with latest android sdk and install it in your device. It means actually you are using latest android.jar(you can see android.jar in your project) file while compiling/Executing code.
Now If you install your application in ginger bread device then android.jar(latest) has a backward compatibility(if required) to run code in Gingerbread device.and if you define target sdk version 10 and running app on Higher API level ,then it will run smooth except your compatibility behavior disable in respective device other than targeted devices.
I have a PhoneGap 3.1 project running on Android which is working fine - compiled with Android API lvl. 19. However, the native dialogs/alerts are using the Froyo/Android 2.x look and feel, whereas I'd like them to use the ICS/Android 4.x look and feel. In an older version of my , I did manage to get the dialog theme using ICS by updating the targetSDKVersion in AndroidManifest.xml. However, this has not worked in my 3.1 project.
This is an example of how they look in the version of my app running PhoneGap 2.5:
This is an example of how they look in my app running PhoneGap 3.1:
I do believe this to be less of a PhoneGap issue, but more an Android Eclipse project setting. But I have the no idea what I need to change to fix this? Could someone advise please? Thanks!
Don't worry - fixed it myself. For those who want to know, there is the following tag set in the default manifest file. By default, this is set to:
android:theme="Theme.Black.NoTitleBar"
Changing it to the following fixed it:
android:theme="Theme.DeviceDefault"
Quite simple I guess :).
Update
As of org.apache.cordova.dialog v2.9.0, the guys on the Cordova project changed the Android source to contain a default theme value to a hard coded value, as follows:
new AlertDialog.Builder(cordova.getActivity(), AlertDialog.THEME_DEVICE_DEFAULT_LIGHT);
It is frustrating, but you can comment out this line and replace it with:
new AlertDialog.Builder(cordova.getActivity());
To restore previous behaviour and have Cordova use the value specified in AndroidManifest.xml.
I am making application with target SDK set to 17 and min to 8.
So for some features I have to use Support library v4
Question is how can I test it works on older devices?
I am testing on my phone - which has 4.2.2; and I don't have others with older ones
Will creating emulator with 2.3.3 be true test?
tnx
Update
Just for example: I use Fragment in my code (from android.app, not from support library) - even if my minSDK is 4 - I don't see any warnings...should I?
Yes. It is an emulator (not a simulator) so it is very similar to running your code on the corresponding phone.
Another good practice is to run the Lint tests from times to times, they can detect many common mistakes in your code (including compatibility).
Your ide (both Eclipse & Android Studio plugins do this) will also display warning for obvious calls to functions that don't exist at your chosen min API level.
Most of the time emulator behave same if we consider layout view and
other stuff like look and feel performance , but that can be
difference in case of speed performance and sound quality
.
I found one online tool which are providing that service please go through that link , https://appthwack.com
apache lint (from tools) is the answer - shows all problems
I just excavated a maybe 3 months old Phonegap (for Android) project from my archives. Since I always had little problems with the sound API (sounds playing twice or not stopping - the rest was working just fine) I thought it might be a good idea to update to the latest version of Phonegap / now Cordova, which currently is 1.9.0. Unfortunately the app now crashes on startup (telling me it was forced to stop unexpectedly in an alert box) in all devices that I can test on (virtual and real handsets).
I guess I might have forgotten something in the update process so I'll just list what I actually did during the update:
replaced the JAR file to 1.9.0
replaced the JS library to 1.9.0 (and replaced the reference in the index.html
Edited my AndroidManifest.xml to match this page
Replaced the plugins.xml content with the new version
Replaced the phonegap.xml in the resfolder by the new cordova.xml
changed the imports in the main AppActivity.java file
Updated the all the SDK packages in Eclipse
Somehow this doesn't seem to suffice.
Did I just miss something that still needs to be done or is this some problem with something that I am doing inside my app? I didn't use any Cordova API except for playing Sounds.
minSdkVersion is 8 by the way.
Ok, so what did the trick (kind of) for me was to create a new Project in Eclipse, set it up the exact same way and just incorporate my www folder into the new project.
The two projects look exactly the same but lord only knows that I probably have missed something. In case anyone still has input on this, don't hesitate to share it!
I have an app to release which works on all android screen-sizes (except smaller) and densities above SDK version 2.0.
It will also run on extra large screens.
Currently I have added this:
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="false"
android:anyDensity="true"
/>
But I also need to add android:xlargeScreens="true" , to allow it visible in android market on extra large screen devices, since by default it is false.
But to add android:xlargeScreens I need to change my eclipse targetsettings to 2.3 as this attribute was added from API level 9.
So what should I do with my target compilation settings for this scenario ? Should it be 2.3 while compiling ? If yes, then will the app not give any problems while running on devices with 2.0 version ?
Yes you need to change the uses sdk to 2.3 but make sure that you are not using any newer apis which are not in 2.0 or whatever your minimum supported sdk version is. Or in case you want to use them you have to use reflection.
But more about how to use the sdk versions is here and more about uses-sdk is here.
I do the same in my application and make sure you test your application in both[all] the versions before you release.
Best,
Achie.
I'm moving this from the comments to make it more clear for others looking at this question in the future.
When supporting both old and new versions of Android it can be confusing how applications manage to run despite many things change with in the frameworks during each new release, I'm going to try and clarify this here.
An application written for the 1.5 sdk can only call functions that exist for that API level, so for instance the multi touch api's didn't exist in 1.5 and never will. Now you say "Ok but I don't need to call any newer APIs, I just want my app to work in 2.3 and have a2sd support" And I say "Ok, just change your targetApi in the manifest, set the minSDK and compile against 2.3 and you're good to go."
Now why does that work? What if the onMeasure() method for ListView was changed in 2.2 and now calls betterCalculateFunction() within onMeasure()? Why does my app still work?
This is the advantage of late binding in Java. You see, Java is never compiled until it reaches a device and is running, what you are doing in Eclipse is converting it to byte code which contains a bunch of byte code instructions that are later interpreted by the device. The byte code will NEVER contain a reference to betterCalculateFunction() though (unless you directly call it. Calling onMeasure() is indirect). This can happen because when your code is running on the device it gets linked against the Android framework on the device and your code calls onMeasure() directly because it is a public outward facing API. The path of execution will then enter the framework and call whatever it needs to, then once its done return to your code.
So on 1.5 you might see
doStuff (your code) -> onMeasure
(public API) -> done
and 2.2
doStuff (your code) -> onMeasure
(public API) ->
betterCalculateFunction (private
function) ->done
Now if you need to call functions that may or may not exist depending on API level then I suggest you look at a related answer of mine here stackoverflow: gracefully downgrade your app
Hope that clears some things up.
I haven't tried 2.3, but that's what I do with 2.2.
I compile for 2.2 and test on 1.6 to make sure everything works how I'm expecting. I haven't run in to any issues with it.
To double check, set your target for 2.3 and then setup an emulator for a lower rev version to make sure it all works.
The default value for android:xlargeScreens is true, so you don't have to change anything - it's on by default, as long as your minSdkVersion or targetSdkVersion is higher than 4.
http://developer.android.com/guide/topics/manifest/supports-screens-element.html
Here is an official Android developer blog explanation of how this works:
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
In summary: you can use the newest XML whilst still supporting the older OS versions in a back compatible way.
While reading this blog post I guess I have an answer on my old question. An extract below (which is for another manifest attribute "requiresSmallestWidthDp" introduced from 3.2):
"The catch is that you must compile your application against Android 3.2 or higher in order to use the requiresSmallestWidthDp attribute. Older versions don’t understand this attribute and will raise a compile-time error. The safest thing to do is develop your app against the platform that matches the API level you’ve set for minSdkVersion. When you’re making final preparations to build your release candidate, change the build target to Android 3.2 and add the requiresSmallestWidthDp attribute. Android versions older than 3.2 simply ignore that XML attribute, so there’s no risk of a runtime failure."
For different screens you have to create multiple apk then it reduces size of your application.In each application's manifest you have to define according to following link.
http://developer.android.com/guide/practices/screens-distribution.html