After API 17 / RTL support was released, I added the following to my manifest
android:supportsRtl="true"
which caused Lint to rightfully give me these warnings wherever I had paddingLeft/Right in my views:
Consider adding android:paddingStart="8dp" to better support right-to-left layouts
Consider adding android:paddingEnd="8dp" to better support right-to-left layouts
I did this following the guidance found in this android-developers blogpost, which implied that we did not need to create a new layout-v17 file, but rather could just use both the paddingStart/End as well as the paddingLeft/Right attributes (the Left/Right were required to continue supporting a lower minSdk).
I just made the update to Android Studio 1.0 from the previous Beta version, and am noticing a new lint error which states:
Attribute paddingStart referenced here can result in a crash on some specific devices older than API 17 (current min is 7)
and the suggested fix is:
Override Resource in layout-v17
Which makes sense. However, after creating layout-v17 and removing the unused paddingStart/End from the main layout folder, the original Lint warnings have reappeared saying that I should use paddingStart/End. It seems like it does not understand that I have overrided the files in layout-v17.
Does anyone know how to solve what seems to be conflicting Lint error/warning messages? I know I can just tools:ignore the warning, but I am hoping for a "proper" solution.
Edit (1/19/15): There is an android issue that I imagine led to the new lint error being added to Android Studio. This suggests that the "crash on some specific devices" refers to a handful of Samsung tablets on API16 where paddingStart has its own definition and as such crashes when it tries to parse "8dp".
Some people in the above link have suggested to use the layout-ldrtl folder to handle the rtl direction, rather than using paddingStart and paddingEnd.
I've also had a suggestion elsewhere to override the LayoutInflator's Factory2 whenever you find that the user has a API16 tablet, and then manually set the attributes of all your views. This will certainly work, but it seems extremely "manual".
I unfortunately don't have access to one of these devices that crash, so I can't verify why I have not found anyone online suggesting simply putting paddingStart in /layout-v17/ folder, and paddingLeft in /layout/? Do the API16 Samsung tablets somehow still continue to crash despite paddingStart only being present in layout-v17?
You're right about the root cause of the issue - Samsung defined a custom attribute for the id reserved for paddingStart or paddingEnd.
The way I by-passed this was to extract the padding properties and put them into a style. So instead of having different layouts for SDK<17 and SDK>=17, I have different styles for them (with paddingLeft&Right in values and paddingStart&End in values-v17).
This way, Lint will stop complaining about it.
Its just a suggestion. I hope you have solved your problem by now.
If you set your minimum SDK level below 4.1, then you have to explicitly mention the padding as paddingLeft and paddingStart. For SDK level above 4.1, you can use paddingStart. I am guessing (as I have never faced it before), as you set your SDK level to 2.2 or below 4.1, android sdk level is going crazy.
Related
We're trying to make our apps more accessible, and one of the things we're looking at is supporting larger font sizes when configured from the system settings.
We noticed that on Android 7.0 (and probably earlier versions too), the system font sizes are not properly applied within our app. We also noticed that some other apps like gmail were properly handling the font size change, so it was "something" our app was doing wrong. After quite some time investigating we found out that using the androidx library seems to be the cause.
For example, creating a "hello world" new project under Android Studio, you'll see a "use androix artifacts" checkbox:
Then, if you set the accessibility font size to the highest value:
This will be the result for your app if you checked the "androidx" checkbox (not working):
This will be the result for your app if you didn't check the "androidx" checkbox (working properly):
If you check that box, the produced app binary will not apply system accessibility font size changes properly on Android 7.0, otherwise it will work fine.
Migrating to androidx was a little bit of work and since it's the future (the support library is gradually getting deprecated), going back is not really an option :/
Has anyone else encountered a similar issue?
Could that be a bug with the androidx library?
If anyone found a way to keep the androidx library and not have this bug, I would really like to know about it, thank you in advance!
Update your implementations, example:
implementation 'androidx.appcompat:appcompat:1.2.0-alpha01'
You may also need:
implementation 'com.android.support:support-v4:28.0.0'
I really don't know which information to put in here because the problem is so silly and ridiculous that I don't have a clue as to what might matter in order to understand it.
I was just working on a project yesterday night and after encountering a nasty android "bug"? (something to do with bitmaps disappearing from internal memory) I decided to shut down and keep on working today.
This morning I opened IntelliJ and suddenly the xml layout preview goes crazy:
NOTE: One or more layouts are missing the layout_width or
layout_height attributes. These are required in most layouts. Or:
Automatically add all missing attributes Couldn't resolve resource
#string/app_name (46 similar errors not shown) "#dimen/logo_font_size"
in attribute "textSize" is not a valid format. (Edit) (25 similar
errors not shown)
It says that some layout_width or layout_height is missing, but none of these attributes is missing from any element. I know because the project won't build if there is such an error and I built the same project multiple times yesterday without any problems.
Additionally, every string, dimen and color resource cannot be resolved anymore even if the files are still there unchanged.
I did not pull from git or any other repository. I did not modify the project in any way in the meantime, and xmls have been left untouched. I did not install any android sdk component, tool or update in the meantime.
I already try to restart IntelliJ many times; I also tried to rebuild the project; but nothing works.
here I face one problem after updating this both API level 20 (L and W). in my XML Graphical view the layout is not generated instead it is showing me this error:
Missing styles. Is the correct theme chosen for this layout?
Use the Theme combo box above the layout to choose a different layout, or fix the theme style references.
and also shows an error in res/values/styles.xml in this line
style name="AppBaseTheme" parent="Theme.AppCompat.Light
I use Eclipse juno.
To keep it simple, what you can do is select API 19 in the graphical layout and keep targetSdkVersion="19" and that should solve your problem. Basically the issue is with API20 bundles by google.
More insight about the issues with API 20L or 20W are already highlighted at below SO questions already...I've also responded with the google bug tracking link. Please have a look at those...
Many many issues, eclipse, android MediaPlayer, etc
latest 'ADT BUNDLE' open as JUNO eclipse for windows 7 64 bit
Hope this helps...
This is the error I'm getting in my layout XML files:
error!
NotFoundException: null
Exception details are logged in Window > Show View > Error Log
The following classes could not be found:
- TextView (Change to android.widget.TextView, Fix Build Path, Edit XML)
This happened after updating my SDK tools in Eclipse. However, I can still compile my code, I just can't see the graphical part of my layout.
Recently, I also added the RootTools library, could that also be the cause?
Thank you!
I had the same problem. And it turned out to be a very strange thing.
In my strings.xml file I had a line
<string name="email_seperator_char">\#</string>
And this was causing the problem. Even if I use the escape character for # sign preview was not working after SDK update.
SOLUTION:
I just added a space in front of it and voila, it worked.
<string name="email_seperator_char"> \#</string>
I know it is strange and it may not be acceptable for some apps to have an space infront of it. But that was ok for my app. Hope this helps.
And in design mode, in graphical layout, you have a new icon, (android icon), click and select 8 minimum.
I'm not sure it helps in your case, but I found out what was the problem with mine. To support older Android devices, I lowered my project build target to API level 7 (Android 2.1) from the previous value of API Level 8 (Android 2.2).
There might be an issue with the 2.1 layout renderer, it kept crashing on my TextView's property android:textAppearance="?android:attr/textAppearanceMedium". Even when I removed it, rendering was working but had a strange appearance (grey background, tiny black text). Switching the API level back fixed the layout editor straight away.
To change it, go to your project properties, select Android on the right, then tick the box next to your desired API level under Project Build Target.
I ve got the same issue just a minutes ago, try to lower the API level, press the andorid green icon in the layout editor screen and on the dropdown menu select API 7. I think it would be work out.
I've been having similar issues. After reading a number of these posts, I've found that there is probably a bug in the layout renderer for Android 4.0.3. An error message is listed (ROOT
Exception details are logged in Window > Show View > Error Log) even when all parts of the project are set to Android 4.0.3 and SDK 15.
If I set the layout renderer to Android 2.2 and leave everything else set to Android 4.0.3, SDK 15, then it all appears to work just fine.
I hope this is useful.
there is something wrong in your TextView
one time I wrote this which cause the problem
android:textAppearance="#android:attr/textAppearanceLarge"
the Eclipse can`t tell that is wrong but the design view crashes,when I realized that,I change # to ?
android:textAppearance="?android:attr/textAppearanceLarge"
then all comes to normal
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