About the problems caused by android:targetsdkversion

The last two days have been struggling with a problem, is that our new version of the software through idea compiled out of the 4.4 mobile phone on the entire camera UI is completely chaotic, colleagues several mobile phones are the same, the appearance of confusion is the entire UI compression squeeze together, not exactly what you set in the layout and the relative position of the appearance. However, it is normal to see the layout shown by the design button of the idea's layout file, so it has always been suspected of being a compilation problem, or whether the ID of some controls is duplicated. Then re-rebuild, re-delete the Out,gen directory, recompile, the problem remains. Dizzy Oh, what's going on? So, I want to carefully analyze the next. So casually and with Meizu 4.1 system of mobile phone to try the next, the result, I rub, incredibly normal, how to go? Asked colleagues have recently changed the camera-related code, said no. I read the submission record, indeed no Ah, how is it possible? Really do not understand, and then trace the previous record, found that changed manifest inside a place is android:targetsdkversion this attribute, Halo, this zodiac and camera UI show has yarn relationship, hey, or see it. Colleague from android:targetsdkversion = 14 changed to Android:targetsdkversion = 19, so restore try, results, I went, incredibly run OK, and then change back to 19 try, rub, and not OK. Well, the reason for finding it is android:targetsdkversion, but why does android:targetsdkversion affect the display of the camera UI? Unrelated Ah!! Android:targetsdkversion=, the Targetsdkversion property tells the system that the application is being tested on a system with an API level of 14, and that the application does not allow upward compatibility behavior. When an application runs on a system with a higher version of the API level, the app runs in the targetsdkversion version, without the need to display it based on a higher version of the system. But why does this problem occur?         Next I looked at the description of the next 4.4 system API, inside the Build.java class/** * Android 4.4:kitkat, another tasty treat. * * <p>applications targeting this or a later release would get these * new changes in Behavior:</p> * <ul> * <li> The default result of {Android.preference.preferenceactivity#isva Lidfragment * Preferenceactivity.isvaluefragment} becomes false instead of true.</li> * <li> I n {@link Android.webkit.WebView}, apps targeting earlier versions would has * JS URLs evaluated directly and any R  Esult of the evaluation won't replace the current page content. Apps targetting KITKAT or later that load a JS URL would * has the result of that URL replace the content of the C         Urrent page</li> * <li> {@link android.app.alarmmanager#set alarmmanager.set} becomes interpreted as * An inexact value, to give the system more flexibility in scheduling alarms.</li> * <li> {@lin K android.content.context#getsharedpreferences (String, int) * Context.getsharedpreferences} no longer allows a nul L name.</li> * <li> {@link Android.widget.RelatiVelayout} changes to compute wrapped content * Margins correctly.</li> * <li> {@link android.a Pp. ActionBar} ' s window content overlay is allowed to be * drawn.</li> * <li>the {@link Android. Manifest.permission#read_external_storage} * Permission are now always enforced.</li> * &LT;LI&GT;ACC         ESS to package-specific External storage directories belonging * to the calling app no longer requires the * {@link Android. Manifest.permission#read_external_storage} or * {@link Android. Manifest.permission#write_external_storage} * permissions.</li> * </ul> * * Publ IC static final int KITKAT = 19; there's a saying. android.widget.RelativeLayout} changes to compute wrapped content margins correctly , said that the relativelayout calculation of the margin of the way, I think, may not be related to the change of relativelayout? Then went to see the API description of Relativelayout. Rub, this seems to have a problem, relativelayout inside Introduction said Note:in platform version and lower, Relativelayout was Affected by a measurement the bug that could cause the child of the measured with incorrect MEASURESPEC values. (see Measurespec.makemeasurespec for more details.) This is triggered when a relativelayout container is placed in a scrolling container, such as a ScrollView or horizontal ScrollView. If A custom view not equipped to properly measure with the Measurespec mode Unspecifiedwas placed in a relativelayout, thi s would silently work anyway as relativelayout would pass a very large at_most measurespec instead.  This behavior have been preserved for apps that set android:targetsdkversion= "+" or older in their manifest ' s USES-SDK tag For compatibility. Apps targeting SDK version or newer would receive the correct behavior he said relativelayout inside Measurespec.makemeasurespec in 17 Before the implementation is problematic, 17 after the change, oh, measurespec.makemeasurespec This method has a problem, well, continue to investigate.        Our camera UI is written like this <com.pinguo.camera360.camera.controller.cameralayout android:id= "@+id/layout_camera_container" Android:layout_width= "Fill_paRent "android:layout_height=" fill_parent "android:background=" #ff000000 "> <!--preview Framing area, ID cannot be changed arbitrarily --<include android:id= "@+id/layout_camera_preview" layout= "@layout/camera_preview_con             Tainer "/> <!--bottom Bar,id cannot be changed--<include android:id=" @+id/layout_camera_bottom_bar " layout= "@layout/layout_camera_bottom_menu2"/> &LT;/COM.PINGUO.CAMERA360.CAMERA.CONTROLLER.CAMERALAYOUT&G   T   This cameralayout is a custom view that inherits ViewGroup,----public class Cameralayout extends ViewGroup----- Then cameralayout inside rewrite the Onmeasure method, also used the Measurespec.makemeasurespec method, well, there may be problems, continue to @Override protected void onmeasure (in        T widthmeasurespec, int heightmeasurespec) {super.onmeasure (Widthmeasurespec, Heightmeasurespec);        int width = measurespec.getsize (widthmeasurespec);        int height = measurespec.getsize (heightmeasurespec);        Calclayoutrect (width, height); Final int count =Getchildcount ();            for (int i = 0; i < count; i++) {final View child = Getchildat (i); if (child.getvisibility () = view.gone) {switch (Child.getid ()) {//Is this android:id= "@+id/layout_camera _preview "Case Preview_id:int wm2 = Measurespec.makemeasurespec (measurespec.exa                        Ctly,prelayrect.right-prelayrect.left);                        int hm2 = Measurespec.makemeasurespec (measurespec.exactly,prelayrect.bottom-prelayrect.top);                        Child.measure (wm2, HM2);    Break This is the android:id= "@+id/layout_camera_bottom_bar" case bottom_id:int WM3 = Meas                        Urespec.makemeasurespec (Measurespec.exactly,botlayrect.right-botlayrect.left);                        int hm3 = Measurespec.makemeasurespec (measurespec.exactly,botlayrect.bottom-botlayrect.top);                        Child.measure (WM3, HM3); Break                    Default:break; }}}} look carefully and discover measurespec.makemeasurespec (prelayrect.right-prelayrect.left,measurespec.exactly); The method parameter is reversed, public static int makemeasurespec (int size, int mode) method The first one should be size, the second is mode, but we are not careful to write the wrong. So why write wrong, has not been wrong, the user did not feedback it, should not AH. Continue to see the source code when we put android:targetsdkversion= "14" configured to 14, that is, using 4.0 of the implementation, 4.0 of the source code Makemeasurespec is implemented, 4009/**14010 * Crea  TES A measure specification based on the supplied size and mode.14011 *14012 * The mode must always be one of the following:14013 * <ul>14014 * <li>{@link ANDROID.VIEW.VIEW.MEASURESPEC#UNSPECIFIED}&L t;/li>14015 * <li>{@link android.view.view.measurespec#exactly}</li>14016 * <li>{@l  Ink android.view.view.measurespec#at_most}</li>14017 * </ul>14018 *14019 * @param size The size of the measure specification14020 * @param mode theMode of the measure specification14021 * @return The measure specification based on size and mode14022 */1 4023 public static int makemeasurespec (int size, int mode) {14024 return size + mode;14025} uncle, this Is the above system said that the problem, the implementation of whether you pass the parameter is not reversed, are returned the same result. So, configured to android:targetsdkversion= "14, even if the parameters are reversed, no problem. If you configure android:targetsdkversion= "19", then run the code with a 4.4 implementation.         The 4.4 modified implementation is such that/** * Creates a measure specification based on the supplied size and mode. * * The mode must always be one of the following: * <ul> * <li>{@link android.view.Vi ew.         measurespec#unspecified}</li> * <li>{@link android.view.view.measurespec#exactly}</li> * <li>{@link android.view.view.measurespec#at_most}</li> * </ul> * * <p>& Lt;strong>note:</strong> on API level and lower, MAKEMEASURESPEC's * implementation is such that the Order of ArgumenTS did not matter * and overflow in either value could impact the resulting measurespec.         * {@link android.widget.RelativeLayout} is affected by this bug.         * Apps targeting API levels greater than + would get the fixed, more strict * behavior.</p> *         * @param size The size of the measure specification * @param mode the mode of the measure specification * @return The measure specification based on size and mode */public static int Makemeasurespec (int size, I            NT mode) {if (Susebrokenmakemeasurespec) {return size + mode; } else {return (size & ~mode_mask) |            (Mode & Mode_mask); } What is}susebrokenmakemeasurespec? From the source, it is used to match. Older apps may need this compatibility hack for measurement.susebrokenmakemeasurespec = targetsdkversion <= JELLY_BE AN_MR1; Yes, the problem is found, when you configure android:targetsdkversion= "19", at this time Susebrokenmakemeasurespec = = False,Then the logic to go is return (Size & ~mode_mask) | (Mode & Mode_mask), because this time we have the method parameters sent, so that the UI layout is the whole problem, confusion. When the android:targetsdkversion= "14" is configured, In time currently running in 4.4 of the mobile phone, Susebrokenmakemeasurespec also for the ture, the system goes or the old error implementation mode layout (although it is wrong, but Google can let it run normally, just realize the wrong), so, it is OK. And that's why.

About the problems caused by android:targetsdkversion