The last message before crash in the log:
LOGCAT: F/art (22502): art/runtime/mirror/art_method.cc:356] Check
failed: !IsFastNative() int java.lang.Character.digitImpl!(int, int)
...and I have no clue what does this function check.
The source code available here(https://android.googlesource.com/platform/art/+/refs/tags/android-cts-5.1_r21/runtime/mirror/art_method.h)
bool IsFastNative() SHARED_LOCKS_REQUIRED(Locks::mutator_lock_)
{
uint32_t mask = kAccFastNative | kAccNative;
return (GetAccessFlags() & mask) == mask;
}
Same app, armv7a build runs like a charm
Same app, armv8a build, Android 10 runs like a charm as well.
What can be the reason? Any ideas are appreciated.
Looks like this is happening because of a bug in the latest qt 5.15.0
Fresh issues:
https://bugreports.qt.io/browse/QTBUG-85493
https://bugreports.qt.io/browse/QTBUG-84849
I'm debugging my Android app in Android Studio, and it failed to find execution point of native code, as a result, variables also cannot be shown:
World::flush looks like this:
void World::flush() {
LOGE_LS("Flushing cached chunks...");
for (chunk_lru_li *i = lru, *j; i != nullptr; i = j) {
if (i->item->flag == CHUNK_LI_DIRTY) {
LOGE_LS("Saving chunk (%d,%d).", i->item->key.x_div16, i->item->key.z_div16);
i->item->val->save();
LOGE_LS("Saved chunk.");
}
j = i->next;
delete i->item->val;
delete i->item;
delete i;
}
lru = nullptr;
mru = nullptr;
num_chunks = 0;
memset(chunks, 0, sizeof(chunks));
LOGE_LS("Flusing done.");
}
Debugger type was set to Native.
Threads and call stack are displayed.
This used to work several months ago within the same project.
Release version of a shared library was used but does not seems to be the reason.
I tried many variables of different functions in the call stack, not only the lru in screenshot.
Build variants of all modules are debug (Otherwise the app won't be debuggable at all)
Thanks meow~
Solved by searching on CSDN blog:
Find your module that contains c/c++ code, open its iml file on the Project panel:
find this tag: <facet type="native-android-gradle" name="Native-Android-Gradle">
under the tag find <option name="SELECTED_BUILD_VARIANT" value="release" />
change release to debug. If it's already debug then it seems not the reason to your problem.
Save & Close the file then do Gradle sync.
It should be fixed now. If not, clean build may or may not help.
Link of original answer at CSDN blog: https://blog.csdn.net/wangyun522/article/details/78820569
It's not in English and you may not want to check it out.
Since update AS 1.1 Preview 2, I'm getting red lines under all my Log messages
Log.d(TAG, "message");
With message: "The logging tag can be at most 23 characters..".
I didn't update anything fundamentally, except Android Studio itself. Is this a bug?
You can disable it if you so choose.
In Android Studio, Analyze->Inspect Code.
Under Inspection Profile, click on the button with the 3 horizontal dots.
The following window should open. Search for "log" and uncheck "Too Long Log Tags".
Update: Android Studio 2.2, it is located under Android Lint: Correctness
No, it's not a bug.
From Android Studio's Recent Changes on 1.1 Preview 2,
Checks that the tag passed to the logging calls, if its value can be resolved, is at most 23 characters long (as required by the Logging API.)
As shortly explained on the recent changes, it's due to how Log API doesn't allow tag that exceeds 23 characters.
SLF4J Android has an explanation to this:
[...] the length of such tags is currently limited to 23 characters (23 = 32 - 8 for namespace prefix - 1 for C terminator)
which matches the Android's source code.
Currently, the only function that explicitly mentions this exception is Log.isLoggable(),
...
Throws
IllegalArgumentException is thrown if the tag.length() > 23.
However, based on the comments, apparently the logger does throw the exception on release mode (it's ignored in debug mode).
You can disable the lint checking by following Terence's answer, but you've been warned.
Complementing the answer by #Terence
You can also turn off the specific check via gradle with this in your build.gradle file:
lintOptions {
disable 'LongLogTag'
}
Or by adding a lint.xml file to your project with xml:
<?xml version="1.0" encoding="UTF-8"?>
<lint>
<issue id="LongLogTag" severity="ignore" />
</lint>
You can never ignore this lint check, it definitely could bring unexpected results on your release version since it throws exceptions and stops executing (it would not crash your app).
I have had a terrible lesson learned recently: it's OK on debug mode, but behave differently on release version.
This is recent change and In this build, its a new lint check. Which says,
Checks that the tag passed to the logging calls, if its value can be resolved, is at most 23 characters long (as required by the Logging API.)
For more info, read 3rd point in below link.
https://sites.google.com/a/android.com/tools/recent/androidstudio11preview2
If you dont want to get this, minimize the number of characters in your TAG and make sure that they wont cross the length more than 23.
To explain why this happens:
According to AOSP source code you can log with any tag you want. The problem is in Log.isLoggable.
Log.isLoggable checks the system property log.tag.<YOUR_TAG> if the priority you want to log is enabled. Here's documentation of this mechanism:
public static boolean isLoggable (String tag, int level)
Checks to see whether or not a log for the specified tag is loggable at the specified level. The default level of any tag is set to INFO. This means that any level above and including INFO will be logged. Before you make any calls to a logging method you should check to see if your tag should be logged. You can change the default level by setting a system property: 'setprop log.tag. ' Where level is either VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT, or SUPPRESS. SUPPRESS will turn off all logging for your tag. You can also create a local.prop file that with the following in it: 'log.tag.=' and place that in /data/local.prop.
Source: https://developer.android.com/reference/android/util/Log#isLoggable(java.lang.String,%20int)
Below API 26 (Oreo) the limit of system property keys was 31 characters. And "log.tag.".length() + 23 equals 31. If you call Log.isLoggable below Android Oreo with a tag longer than 23 characters it will throw, as described in the source code. Since Android O this limit no longer applies.
The Lint rule exists just to shield you from all these (typically) unnecessary details.
The documentation for Log.isLoggable also states the IllegalArgumentException will not be thrown since API 24, which according to my findings, is wrong. Follow: https://issuetracker.google.com/issues/124593220
Solution. Year 2020 ver.
build.gradle (app)
android {
lintOptions {
disable 'LongLogTag'
} // put this.
}
This error was thrown for me for a node_module library, complaining about a separate node_mode library.
I added this lint options property within that node_module library's build gradle file.
android {
lintOptions {
abortOnError false
}
}
The library was aws-amplify push notification.
Error:
Execution failed for task ':#aws-amplify/pushnotification:lint'
File updated: node_modules/#aws-amplify/pushnotification/android/build.gradle
When I do this:
try {
workbook = new HSSFWorkbook(new FileInputStream(mInputFile))
} catch (Exception e) {
...
}
My android project work in debug time but crash in run time.
I Use apache POI 3.9
I suspect it could because of the missing java.rmi.UnexpectedException
Thanks Gagravarr..
As metioned on this http://poi.apache.org/changes.html link, "Avoid using RMI based exception from PropertySetFactory, as it's not needed nor helpful" is been fixed in Version 3.10-FINAL (2014-02-08).
Use, 3.10 Final or upper version to get rid of 'java.rmi.UnexpectedException' error.
It looks like a mistake in PropertySetFactory - there's no reason for it to be using a RMI exception, as there's no RMI involved. My hunch is that it's the RMI class that's confusing Android.
I've raised this as bug #55901, and it's fixed as of r1551832. If you grab a nightly build from tomorrow, or do a SVN checkout and build yourself, it ought to now be fixed.
BACKGROUND
I am developing an android application that needs to work on API levels from 7 to 16.
THE PROBLEM
Whenever I go to build my project this is the process I have to go through.
Clean project
Run Project
"Errors in project" > Click OK > Run Project Again
Runs fine on any API
I think the problem is due to the fact I am including code (such as the ActionBar) that API < 3.0 can't use but I am checking for it and running something else if thats the case.
THE QUESTION
Does anyone know a way round this because it is very time consuming considering I have to do this every time I want to run it.
I suppose you are using Eclipse for your development. You can annotate the offending methods as follows:
private final int VERSION = android.os.Build.VERSION.SDK_INT;
private File myDir;
// some stuff here
#SuppressLint("NewApi")
private void doSomething() {
if (VERSION < 8) {
// Uses a method available since API 1
myDir = Environment.getExternalStorageDirectory();
else {
// Uses a method available since API 8
myDir = getExternalFilesDir(Environment.DIRECTORY_PICTURES);
}
// Do more stuff
}
You can add in your manifest:
<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="16" />
Then any API between and including 7 and 16 versions will compile because your target is 16.
Then if your device is 7 any API > 7 will fail on your device but you have said you are taking measures against that in your code.