WHen i try to initialize milennial media it show error. screen shot attached.
MMSDK.Inititalize(context); inside activity onCreate();
In order to avoid the VerifyError, you must compile all your classes using the same version of Java. Also, once you make a change to a class, then make sure that you re-compile your project from scratch. Finally, if your application makes use of external libraries, verify that you use the appropriate version of every library and of course, consult the corresponding javadocs, in order to be sure that everything is correct.
Was using latest MMSDK version 5 when i used MMSDK version 3 its working fine.
Related
My current phone (Pixel 2 XL) is running the build PQ1A.181105.017.A1. According to source.android.com, that means it was build from branch android-9.0.0_r16. Looking at a source file from that particular branch, for example SignalStrength.java, there is a public method called getWcdmaRscp(). However, it appears this method was added after SDK version 28 was released, so if I try to call it from my app in Android Studio when targeting 28, it doesn't build.
I'm guessing my phone will gladly allow me to call the method in question, so how do I setup my Android Studio to be able to build against that version of the framework?
It appears I would need a new framework.jar, but where can I find that? Please don't tell me I need to download and build the entire AOSP thing locally.
I doubt it was added after API 28 was released. It's annotated with #hide which means, when the SDK was built, it wasn't built in. It's still in the framework itself, but Android Studio doesn't know that.
To get around this, you'll have to use reflection. Something like:
try {
Method getWcdmaRscp = SignalStrength.class.getMethod("getWcdmaRscp");
int rscp = Integer.parseInt(getWcdmaRscp.invoke(signalStrength).toString()); //signalStrength is the instance you have
} catch (Exception ignored) {}
However, that probably won't work. Android Pie introduced restrictions on accessing hidden methods and classes. In Oreo, you could just use reflection. In Pie, most of the classes you try to access will throw a ClassNotFound or NoSuchMethodError exception, because the system prevents third-party apps from accessing them. Certain hidden APIs are still accessible, but there's no definitive list.
You don't need the whole framework.jar
While one way would be to use reflection as TheWanderer suggested, another option is to add the single source file you linked to, SignlaStrength.java, to your project.
You just need to make sure you add it under the original package path /android/telephony
The studio will use it for compilation to resolve method signatures, but when running on the phone the calls will go through to the original framework class.
I didn't see any non public imports in the file, but if it does not compile, you may need to turn it in to a stub, by removing some function internals.
I have task to modify android gingerbread launcher (2.3). I want to download launcher's sources and add some functionality. I have found sources here:
android Gingerbread launcher sources
I download this and import into workspace as is. As a result I get numerous compile errors (some classes are missing, instance variables are missing, etc). Why? I mean why wouldn't it compile? What should I do to make it compile?
P.S. By the way, when project is imported, used platform as per project settings is not 2.3, so I have to manually set it to 2.3. However, numerous errors still remain.
To convert an AOSP application into a standalone SDK application, you will need to find all the "classes and variable not present in the SDK" and remove/replace the references to them. The simplest is to remove the references to them, if the app will still run with reduced functionality. For references to internal resources, you can simply copy those to your project and modify the R values to point to your local copy. You are welcome to examine the "classes and variable not present in the SDK" and determine that you can copy those as well (refactoring them into a new package), in which case you would update your project to refer to the copied and refactored classes.
The easier solution would be to use someone's source where they already did that..Here found one at
Launcher2 full compilable Ginngerbread lancher code
Have a look at here.
It is the Launcher2 from ICS, not GB, but they are very similar.
From Wiki: Note that it is not completely bug free, and adding widgets will crash the app (as it uses a system level permission. Maybe if you installed via root it'll work).
Here's a list of what all I had to do, that I can recall doing:
There are lots of methods like setFastXXX (for example, setFastAlpha()) that aren't available to us. Changing these to setXXX (for example, 'setAlpha()`) worked for me.
Some thing which are available to us via getSystemService() are initialized directly in the code, like the usage of the Vibrator class. These need to be changed to use getSystemService().
I am implementing menus using TWL (http://twl.l33tlabs.org/) in an app written using Libgdx. The app runs fine if I don't start any menus, but as soon as I go to a menu screen it immediately force-closes. Menu screens work fine on the desktop version.
In which build path should TWL-android.jar be included (right now it behaves the same in main, android, and both)? And how will the program know to use the libraries from this .jar instead of the default gdx-twl.jar? Will I have to manually implement something in code to use one or the other depending on platform?
There does not seem to be any documentation or sample code of anyone using TWL on android, only mentioning that it can be done.
Running debugger attached to phone gives the following logcat error:
Could not find class 'com.badlogic.gdt.twl.Layout' referenced from method com.Nanners.OptionsScreen.<init>
I think that TWL-android.jar should be added to android project's build path too. Location of .jar is not relevant.
When you add TWL-android.jar. As that is Android specific you can't use it on the core project, so the classes you are importing are the ones from gdx-twl. To make it simpler to explain I will divide it in different escenarios.
You add TWL-android to your Android buildpath. But you use Gdx-twl in your core project. Which isn't added. Thus getting a:
Could not find class 'com.badlogic.gdx.twl.Layout'
You add both TWL-android AND Gdx-twl to your build path. Thus getting duplicated classes and:
Conversion to Dalvik format failed with error 1
Solution
If you use TWL-android classes, you can only do it inside the Android project:
Merge Core, Desktop and Android project. Or
Use Interfacing with Platform Specific
If you use Gdx-twl:
Don't do it.
Actually the best solution is to get rid of all twl stuff and use Scene2d.Ui instead. Its crossplatform and much easier to use.
I'm developing an API for Android and it works great but I'm not sure how to package/distribute it. I've gotten the "meat" of the API into a jarfile - that's all the classes and an XML file in res/values/attrs.xml (I'm not sure if there's a way users can reference to that without having to copy my attrs.xml into their /values folder, but that's another question).
While trying my API in a test case, I've added my .jar to the build path and I can import a class successfully if I want to, but I don't want to :P My API allows users to implement a custom View into their own XML files, so nothing is instantiated in code.
The question: How can users reference to a custom View in my API? For example, if my View is called FooView and is in package com.myfoo, the following XML fails to load:
<com.myfoo.FooView
android:layout_width="fill_parent"
android:layout_height="100dp"
/>
Does this have to packaged into a jar , As i see facebook android sdk they give out the source code . I set it up as a new android project and from my android project reference this as library.In that case i am able to access all the apis exposed
You might want to look into Android Library Projects. These are basically normal android projects, which can be referenced as a library. This means you can define classes, layouts and resources as you would normally, and just use them in your main app (in this case in your clients app) as if they were defined in the same project. This allows you to reference views in XML like you tried above via <packagename.classname ... />.
There is one huge downside though (which is especially important when you create custom views):
styleable-resources simply don't work. This is a bug.
According to this question it's going to be fixed in the next devtool release though.
With that in mind I recommend setting up a small test project with a test library project and see if everything that you need works correctly.
I just started testing my app on android 1.5, and it doesn't want to run at all. I have a breakpoint in onCreate on my main activity, but I get a ClassNotFound exception even before reaching that. The class not found appears to be the class of my main activity. The exception happens in:
ActivityThread.performLaunchActivity
It runs fine on 1.6 and later, so I assume I'm using something that isn't supported on 1.5. But how can I find out what it is? Any tips on how to debug this would be greatly appreciated.
Thanks.
If you have imported jars, verify that they are in the /libs directory and not in the /lib directory and they are imported as jars and not as external jars
I had the same problem today. It's difficult to identify which class is not supported. The stack trace doesn't really shed any light on it, it just gives the somewhat misleading message that your activity class cannot be found. A couple API's that I have used that I know are not in Android 1.5 are:
- Bluetooth (2.0 and up)
- Text to Speech (1.6 and up)
I ran into this issue because I added support for text to speech to my app and didn't think to check the docs first to make sure text to speech is supported on Android 1.5. I was dismayed to learn it was only added in Android 1.6. To work around the problem I had to do a couple things:
Remove the "import android.speech.tts.*" from my activity
Create wrapper classes that mirror the text to speech API and call the real text to speech classes from there.
Put if statements around the calls to my wrapper class to make sure I only call out to it if the Android SDK level is 1.6 or above. You can check the Android SDK level by inspecting android.os.Build.VERSION.SDK
In your Android Market listing, indicate that the text to speech functionality is only available if you have Android 1.6 or higher installed.
The nice thing about this approach is that in the future, when I decide to abandon support for Android 1.5 I can easily change my calls to my wrapper class to just call the text to speech API directly and rip out the wrapper classes.
I did something similar for my Bluetooth code.