A probe into the Android4.4 production of its own SDK

A probe into the Android4.4 production of its own SDK

        Recently, I have studied the android4.4 to make its own SDK. We all know that after getting Google's original code, the chip company will combine it with the chip to platform, and then send out the chip company's SDK to the customer, this SDK usually contains all the engineering code environment, of course, some of them are published in the form of library, it is required to be confidential. Then we as a mid-stream technology company, there is a certain depth of functional customization, product form changes brought by the SDK a lot of changes, many are tail off completed, of course, this part of the code we also want to be completely confidential, timely we wrap it up again good, also cost energy, but also to complete the process code, good huge, This way of extensibility is not good, scalability is not good, synchronization code is quite troublesome, then we can leave the API, we publish their own SDK to the third party partners, so that the third party can be transferred to their own private API work, and protect their own code, but also save energy. So how do we make the SDK? Here's a look at: /******************************************************************* /
declaration: The content of this blog by the original, reprint please indicate the source, thank you!
/********************************** *******************************************************************/

Android4.4 code volume is quite huge, first we need to set up the environment:

$. build/setupenv.sh

If it is to compile a specific product is lunch specific product model, then go make it.

We want is the SDK, the direct use of "make SDK" is not possible, online some netizens have mentioned, the author also tried, will report a Bluetooth error, go down there will be other errors, specific reasons to have a good analysis of the compilation system to know, supposedly can also go through, the author has not tried. The author then uses "Make PRODUCT-SDK-SDK"

$make PRODUCT-SDK-SDK

The beginning of the compilation is also a large number of errors, the first is "sdk/eclipse/scripts/create_all_symlinks.sh: Line No. 285: cd:tools/base: There is no file or directory "

What do we do? A netizen said with "Repo init–g All;reposync", the author uses the chip company to provide the SDK, not the native SDK, so this method is not feasible. We did not find the Tools/base directory in our SDK, what do we do? Just block it out! The related masks are as follows:

then proceed to compile it down. Also found that the "device\generic\goldfish\camera\emulatedcamera.cpp" This file has errors, had to manually kill the corresponding errors, direct shielding.

Continue to go down, the smooth words can build a while, and then to their own modified code inside, if we in the development of a large number of overlay words, there may be a lot of errors come up, this is mainly due to our usual development is not rigorous, if it is quoted in the code of a resource string, Put in the overlay inside, you compile a specific product, because overlay inside there, of course, will not error, but you compile the SDK, that sorry, not so good to speak, directly is not found resources, exit compilation, there are some layout of XML files, picture files, All the strings need to be copied to the original code location, the result of the usual lazy is to compile the SDK when the huge penalty, that a mistake up, good annoying, dead and wounded brain cells countless.

Based on this point, usually in the application of the time, we still have to be rigorous. Develop a good habit, and work will be much smoother in the future.

These apk compilation problems are visible, but also a lot of heavy, one after the other, no way. The following error is encountered in compiling:

Frameworks/base/core/java/android/widget/earthrotate/glrender.java:44:error 104: @param tag with the name that doesn ' t Match the parameter list: ' Degree: ' Frameworks/base/core/java/android/widget/earthrotate/glrender.java:77:error 104: @param tag with name, doesn ' t match the parameter list: ' Rox ' frameworks/base/core/java/android/widget/earthrotate/ Glrender.java:78:error 104: @param tag with name, doesn ' t match the parameter list: ' Degree: ' Droiddoc took 144 sec. t O Write docs to out/target/common/docs/offline-sdk100 warning MAKE: * * * [Out/target/common/docs/offline-sdk-timestamp] Error 45

look at the back, that is, the comment part of the problem. the changes before and after comparison are as follows:

-/**-* Dynamic rotation angle to rox-* @param rox-* @param degree:change degree every time -*/+/**+ * Dynamic rotation angle to rox+ *+ * @param rox the rox+ *+ * @param degree the Degree change every time.+ */public void Toroatx (final float Rox, final float degree) {int WHA                t = 1; float dx = rox-roatx;@@ -70,11 +72,13 @@ public class Glrender implements Renderer {H.sendemptymessage (w        HAT); }-/**-* Dynamic rotation angle to rox-* @param rox-* @param degree:change degree every Ti me-*/+/**+ * Dynamic rotation angle to rox+ *+ * @param roy the roy+ *+ * @param degree th E degree every time.+ */public void Toroaty (final float Roy, final float degree) {int = 1                ; float dy = roy-roaty; (END)

Difference A look will know, so usually write these comments also to rigorous AH!

To solve the hidden dangers, continue to go down, there will be the following error:

Sdk/build/tools.atree:124:couldn ' t locate source file:tools/base/templates/projectssdk/build/tools.atree:125: Couldn ' t locate source file:tools/base/templates/activitiessdk/build/tools.atree:126:couldn ' t locate source file: Tools/base/templates/gradlesdk/build/tools.atree:127:couldn ' t locate source file:tools/base/templates/othermake: * * * [Out/host/linux-x86/sdk/android-sdk_eng.desheng_linux-x86.zip] Error 44

because there is no tools/base, so we put it off first, continue to compile, successfully completed! See the picture below, heart a burst of joy.

Generated SDK under "Android\out\host\linux-x86\sdk", Android-sdk_eng.desheng_linux-x86.zip, a 680M big dick!

The next step is to verify that the SDK is available.

The method of verification is to extract the compressed file, and then take a call to the private API application to rely on the SDK, compile, see if it can be compiled, and then pushed to the machine inside to run a bit to know. Fortunately, the author's SDK validation passed!

I have to verify that the new project will have some problems, mainly some tools, which may be related to the following tools/base, then for this issue, I would like to solve, with their own usual compiler SDK environment, It is possible to verify this method by replacing the Android.jar at the corresponding API level.

The production of the SDK is a very hard thing, hard work, back to the high efficiency is a huge report! Come on!

A probe into the Android4.4 production of its own SDK