posted Jul 2, 2012, 7:16 PM by Siva Velusamy
ADT 20 includes an NDK plugin that provides support for building and debugging NDK projects in Eclipse. This document describes how to install and use the NDK plugin.
Installation
The NDK plugin currently works with CDT 7.0.2 or CDT 8.0.2. Using the NDK Plugin
1. First set the path to SDK and NDK:
Eclipse -> Window -> Preferences -> Android -> set path to SDK Eclipse -> Window -> Preferences -> Android -> NDK -> set path to the NDK
2. Right click on an Android project and select Android Tools -> Add native support.
Note that you will not be able to add native support if the project already has C/C++ nature.
At this point, you will be able to build your applications using Project -> Build All.
Debugging native applications
1. Update your build config to include “NDK_DEBUG = 1”.
Right click project -> properties -> C/C++ Build:
2. Set a breakpoint in your C code.
3. Right click on your project, select Debug As -> Android Native Application
Note: There is a delay of a few seconds between when the activity is launched and when native debugging starts. If your code is already executed by that point, then you won’t see the breakpoint being hit. So either put a breakpoint in code that is called repetitively, or make sure that you call JNI code after you see that ndk-gdb has connected.
Known Issues
1. Eclipse does not automatically find the include paths to all the NDK headers on Windows. This issue will be fixed in the next update (20.0.1) when it is released.
2. Eclipse does not automatically find the include paths with CDT 8.1.0 (Juno). This issue is tracked in Bug 33788.
|
posted Jun 29, 2012, 4:55 PM by Tor Norbye
[
updated Jul 2, 2012, 7:05 PM by Siva Velusamy
]
The video from our 2012 Google I/O Developer Tools talk is available. You can view it here: It shows some of the highlights of the tools improvements over the last year, as well as a sneak peek at some upcoming features. Note that the audio is missing for the first 10 seconds. Also, you may want to switch to HD video to be able to see the details in the demos.
|
posted Jun 27, 2012, 7:38 PM by Raphaël Moll
The SDK Manager in Tools r20 has two new features frequently requested as feedback.
First, the manager now integrates a cache: - It caches the small manifest xml files that describe which packages are available.
- The cache is only for these small manifest files and does not store any of the large install binaries -- these are downloaded on the spot, installed and then cleaned away.
- The cache is stored in ~/.android/cache or X:\Users\username\.android\cache.
- When the manager starts, it first does a first pass using whatever it currently has then it tries to do a second pass updating cached XML files if they are older than 10 minutes. The result is that in most regular usage, the manager loads a lot faster and you can start using it right away even if the refresh pass hasn't quite finished yet.
- It uses conditional HTTP ETag/Modified headers if the remote server supports them.
- In Tools > Options (or Menu > Preferences on Mac) the user can see the cache size, disable/enable the cache and or empty the cache.
- Command-line users can run "android --clear-cache sdk"
The manager also has a revamped Tools > Manage Add-on Sites dialog that incorporates also another often requseted feature: the dialog allows you to enable or disable third-party sites individually. When a site is disabled, its manifest XML file won't be loaded. Any already installed package will still be listed as usual but you won't be notified of updates and any new addon or extra packages will not be visible in the package list of the SDK Manager.
|
posted Jun 1, 2012, 9:36 AM by Tor Norbye
[
updated Jun 1, 2012, 9:43 AM
]
We've just released a third preview of ADT 20, with the following new features relative to Preview 2: - Eclipse 4.x support: Previous releases of ADT 20 did not work well on Eclipse 4.x. As of Preview 3, the known critical issues (such as cut/copy/paste being broken in XML editors) have been fixed. Please let us know of any remaining ADT-specific issues with Eclipse 4.2.
- Build System
- Automatic merging of library project manifest files into the including project's manifest. Enable with the
manifestmerger.enabled property. - Automatic ProGuard support for the aapt -G flag. This means that the build system will generate a temporary ProGuard keep-rules file containing classes to keep that are referenced from XML files (such as custom views) and pass this to ProGuard at shrink-time. This can make the resulting APK much smaller when using just a small portion of a large library project (such as the Android Support library), since we have also removed the catch-all rules to keep all custom views from the default ProGuard configuration file.
- Execution
- LogCat: Allow users to set colors for different priorities
- Allow running on multiple devices with a single launch. The target tab in the launch configuration dialog adds a new option which allows launching on all connected devices, and a drop down allows the user to further narrow down the list to just physical devices or just emulators. (This applies only to Run configurations, not to Debug/JUnit tests.)
- Lint
- Tighter integration of lint with the layout editor (more details).
- New lint checks:
- Check to make sure that Fragment classes are instantiatable. If you accidentally make a fragment innerclass non-static, or forget to have a default constructor, you can hit runtime errors when the system attempts to reinstantiate your fragment after a configuration change.
- Look for handler leaks: This check makes sure that a handler inner class does not hold an implicit reference to its outer class.
- Duplicate Activity registrations in the manifest. This can lead to subtle errors that can be difficult to understand.
- NDK
- Custom GDB configuration tab
- Add support for debugging on MIPS targets
- Add NDK debug launch shortcut ("Debug as Android Native Application")
- Improve the way the device chooser dialog is handled (should be shown less often)
- XML Editing
- Go to Declaration now works for theme references (?android:attr, ?attr: etc,)
- Improvements to code completion in style definitions
- Completion of the minSdkVersion and targetSdkVersion attributes in manifest files now include version descriptions for each of the API levels
- As of Preview 2, code completion includes custom attributes for custom views. In Preview 3, this is further fixed such that edits to the style files result in the code completion picking up recent edits.
- Settings for the SDK Manager download cache (SDK Manager > Tools > Options)
- More bugfixes
|
posted Jun 1, 2012, 9:27 AM by Tor Norbye
In ADT 20, Lint can now run incrementally on not just XML files, but Java files as well. As soon as you save a file, Lint runs a lint check on the current file and updates error markers on the file. Certain types of checks require "global" analysis, search as "Unused Resources", and those rules are skipped; only checks which can be performed on a single file in isolation are checked. However, it turns out that that's the case for nearly all the Java related checks.
For example, a very common problem for people using the Toast class is forgetting to call "show()" on the result of makeText: Here's another example. Let's say you're trying to set a text color on a button. It has a setTextColor() method, which takes an int. It expects a packed RGB int. However, the resource id for color also happens to be an int, so you might accidentally do this, which compiles just fine:
The error underline here is from lint, not the compiler. And yes -- the above has happened a lot! One of the fun things about writing new lint rules is running lint on large codebases and seeing all the places the error is found!
There are several new lint rules in ADT 20 Preview 3. One of them finds problems with fragments, where either the fragment is a non-static inner class, or it does not have a default constructor, which means that the fragment cannot be reinstantiated by the system if the configuration changes. The lint rule will also warn if the fragment contain other constructors, since this is strongly discouraged. Other recent rules in lint include - a duplicate activity registration check (since if you accidentally register an activity more than once, some really subtle errors can occur. The two elements do not get merged, so you may be adding attributes which are ignored, and so on.)
- a handler leak check, which looks for handler inner classes. If they are not static, the compiler will include a reference to the outer instance, which means the outer object will be retained.
|
posted May 31, 2012, 2:14 PM by Tor Norbye
[
updated May 31, 2012, 2:15 PM
]
Lint helps track down layout layout issues, from internationalization and accessibility problems to performance issues. On every single GUI edit, lint runs incrementally on the currently edited layout. In ADT 20 Preview 3, it's even more tightly integrated into the layout editor:
Here's the screenshot again, this time with each lint-related area highlighted.
First, over in the outline on the right, you can see that there are little error and warning overlay icons in the bottom left corner of any widgets that have associated errors. If you hover the mouse over the icon, the full error message is displayed as a tooltip.
Similarly, in the layout editor itself, there are little warning and error indicators, displayed in the bottom right of each widget that has an associated problem. If you hover the mouse, a tooltip is shown with the associated editor message. Note that in this case the tooltip is shown below the layout editor window. This is done such that simply moving the mouse over the layout design does not cause tooltips to annoyingly obscure the layout you're trying to edit.
Note also that it's possible for multiple views to have lint errors "on top of each other". For example, if you look at the outline above on the right, you can see that both the button and the layout it sits inside provide errors. If you hover the mouse over an area with multiple lint warnings, they're all displayed: Finally, then there's the warning count: This shows up whenever a layout contains one or more warnings, and it displays the number of lint issues found in the current layout. If you click on it, you get a dialog with the full list of errors where you can work through each issue -- reading the issue explanation, applying a quickfix or suppressing the error: |
posted May 16, 2012, 10:43 AM by Tor Norbye
[
updated May 16, 2012, 10:47 AM
]
TL;DR: As previously mentioned, ADT 20 sports a brand new property sheet. Unfortunately, Eclipse by default places the property sheet as a wide window shared with the Console view, the Problems view, etc. The property view works better as a tall and narrow view.
We considered adding a new "Layout Editing Perspective", where we could create an "optimal" window configuration for layout editing, with both the outline and the property sheet arranged vertically. However, switching between perspectives has some distinct disadvantages, especially when you're jumping frequently between editing Java code and tweaking a layout file.
Another option is to do what WindowBuilder does: Embed all the views you need for layout editing inside the editor area itself -- including a new outline ("structure"), a new property sheet, etc. When you maximize the window, you have everything you need. However, this has a disadvantage similar to the perspective-solution: when you switch back and forth between Java and GUI editing, you'll need to maximize and un-maximize, or your Java editor won't show the outline of the Java class.
What we came up with is a hybrid approach which hopefully provides the best of both worlds: no new perspective, and a property sheet shown vertically when you're editing layouts.
The first part of the solution is to simply embed the property sheet into the layout editor's outline view: Notice how the Outline window on the right (which has a blue focus rectangle around it) contains both the layout structure, and the properties. Note however that if you open the actual Property Sheet View in Eclipse, and for example place it on the left hand side where the Package explorer is, then the Outline will immediately drop its own property sheet section and show just the Outline.
The second part of the solution is to support a maximized editor properly. In the above screenshot, you can see both the Package Explorer and the output windows on the bottom, such as the Lint View. When you're editing layouts, especially large tablet ones, you want as much screen space assigned to the layout editor itself. You can maximize the editor (by double clicking on the title tab, or using a keystroke, Ctrl+M). However, with the above setup, this will just show the layout editor and palette, and it will hide the Outline and the Property Sheet.
So what we do now is to also embed the Outline and Property Sheet areas in the layout editor. And this mode is automatically entered when you maximize the editor, and automatically exited when you un-maximize the editor, such that you don't end up with two outlines and two property sheets. Here's how the maximized editor looks: Now the left and bottom views unrelated to the layout editor is gone, and we still have the palette, outline and property views.
If you look carefully you can also see that the window decorations for these views look a bit different. That's because these are not Eclipse views, but instead embedded views based on the WindowBuilder ones. This offers several features. For one thing, you can minimize them by clicking on the little arrow, to for example hide the Palette view -- notice the thing vertical area to the left of the layout with the vertical "Palette" label: If you hover or click over the palette area, you can temporarily expose the palette, and initiate a drag -- and as soon as you do, it will dismiss itself again. This lets you have more permanent available space to view the layout, and only pull up the palette (or outline or property sheet) when you need it: You can also drag these views around a bit to rearrange the layout editor layout. For example, you can drag the palette to the right and the structure view to the left (and the black rectangle in this screenshot is the drop location preview during a drag): Or you could place the structure view on the bottom -- it will display in a horizontal arrangement instead of in a vertical arrangement: One final thing to mention: The palette view should now be more reasonable with how much space it uses. In the previous implementation, we used a widget which only let us assign a percentage of the width, so the palette would always take up 20% of the space, which was unreasonable for both narrow and wide screen sizes. Now it will instead not just have a fixed initial size, but it will also remember the size you assign to it.
With these changes, the new property sheet should be much more useful, since it shows up by default, and stays visible along with the outline even in zoomed/maximized editor mode.
The code to accomplish all this is a bit tricky, relying on listening to various Eclipse window system events and working around some issues, so there's potential for bugs. For that reason we'd really like feedback and bug reports on how it works (it will be available as part of ADT 20 Preview 2). Use the normal feedback channels. |
posted May 16, 2012, 9:30 AM by Tor Norbye
[
updated May 16, 2012, 9:34 AM
]
The Layout Editor has a "configuration chooser" area above the layout editor, where you can choose screen size, orientation, etc: It works just fine, but has some disadvantages: - It takes up a lot of space
- Switching orientations requires multiple clicks
- It's showing some settings that are rarely used
- It does not handle narrow widths well; take a look at what happens to the menus on the second row for example:
In ADT 20, the old configuration chooser has been replaced by a brand new configuration toolbar: Instead of combo boxes, it uses drop down menus, which allows us to use icons, separators and perhaps more importantly, we can lazily compute the contents of the menus.
Here's the locale menu for example, showing the usefulness of icons in these menus: And here's the theme menu. As you can see we now have logical nesting and grouping, so unlike in the old drop down menu you don't have to scroll to find for example Holo.Light.Dialog. And all the themes local to the project, and any themes referenced explicitly in the manifest, are also grouped together: Right to the left of the welcome menu is the orientation menu. You can just click on it to quickly flip orientation, so in the above screenshot the layout is currently in landscape orientation, and the flip button shows the portrait mode. You can also click on the drop down arrow next to the button, to see the other associated options: Notice how the UI Mode and the Night mode have been moved into this menu; they aren't used often enough that they warrant permanent visibility in the layout editor.
And instead, we've added a new menu: The Activity chooser. This lets you choose the activity context to use for this layout: When you open a layout the first time, we attempt to guess the right layout (by looking at your activity classes and seeing which layouts they reference), but you can choose a different activity here. The activity associated with a layout is used to pick which theme to render with, in the case where you've assigned themes to activities in your manifest file. You can also open the activity in the Java editor by choosing "Open activity name". In the future we will also use the activity<->layout association to drive other features.
The leftmost menu lists the current configuration, such as "default", or "layout-xlarge", etc. If you open the associated menu, you can see which other versions of this layout you have: You can also create a new layout (which is what the "Create..." button in the old configuration chooser did). The device menu to its right should be obvious; it's where you choose among the various screen sizes to render your layout with. We plan to add your AVD's into this menu as soon as possible.
And finally, the Android logo on the right is where you pick the rendering target for your layout. Instead of showing the version name (e.g. Android 4.0), we now show just the API number, though in the drop down menu you can see the full labels: While the goal of the new configuration toolbar is to fit in a single line (which is why we abbreviate your screen names, the rendering target name, strip the "Theme." prefix off of theme names etc), in the case where it just won't fit, the toolbar will wrap: We'll have a Preview 2 of ADT 20 out soon. Please give the new configuration toolbar a try and let us know if you see any problems. |
posted Apr 17, 2012, 3:24 PM by Tor Norbye
[
updated Apr 17, 2012, 3:26 PM
]
In ADT 20 we're replacing the property sheet in the layout editor with a much better one (based on the WindowBuilder codebase):
There are several things to note here: - Important attributes are highlighted in bold
- Values which have been edited for this widget are shown in blue.
- Some default values are shown. For example, in this case the Text Color Link is not defined, but the default value is apparently (for this theme) @android:color/holo_blue_light, and a preview of that color is rendered.
- Attributes can be nested; for example, the layout parameters are all nested in a single layout parameters section. All attributes from each defining class (such as TextView) are grouped together. You can use the Collapse All and Expand All buttons in the toolbar to quickly collapse/expand these categories.
- You can switch to alphabetical sorting instead, if you know you want a particular attribute by name.
- Advanced properties are hidden by default, and can be shown if you toggle the show advanced button:
In the above screenshot all the attributes with gray italics labels are advanced attributes which were hidden before we toggled the show advanced button (the leftmost button in the toolbar above). Notice also how it's rendering previews of not just colors, but drawable icons as well; the above shows the default text selection handles on an EditText.
There is improved support for entering values. Boolean values have a tri-state checkbox (on, off, default). The "..." button continues to open the resource chooser, but if you click into a value text field to edit it, you get completion support as you're typing. For example, when you're entering a resource value, it shows the possible completions: And if you're entering an enum or flag, you get completion on the possible values: You can also enter multiple flags: NOTE: The new property sheet works best as a tall window, but the default Eclipse property sheet viewer is a wide window in the bottom area. We're working on a scheme to deal with this, but in the meantime, you may want to simply drag the property sheet window and dock it on the right, either sharing a tab with the outline window, or perhaps better yet docking it below the outline window. |
posted Mar 14, 2012, 3:12 PM by Tor Norbye
The Lint UI was overhauled in ADT 17.
First, there's a dropdown toolbar action which lets you run lint on the selected project, or on all projects, and clear markers: Second, the lint window itself is no longer a long list; it's a hierarchical table, where each top level item represents a unique issue type. This makes it easy to scan through your project to see what kinds of issues lint found, without having to scroll through 200 unused resource warnings for example: By default all the issue types are collapsed; here I've manually expanded the last issue type. You can quickly expand or collapse all items using the + or - buttons in the lint window's toolbar: The other options in this toolbar include - Refresh, which re-runs the current analysis on the same projects
- Fix, which automatically fixes the issue (this applies to issues where a quickfix is available)
- Suppress this issue with an attribute or annotation
- Ignore in this file (saves suppress information in lint.xml)
- Ignore in this project (ditto)
- Always ignore
- Delete this lint marker
- Delete all lint markers
- Expand, Collapse
- Configure Columns
- Edit Options
Configure Columns lets you edit which columns are visible. There are several new columns you can display, such as Category, Priority, etc, and you can click on column headers to sort the display by the given column. There's also a new "Location" column, shown by default, which incorporates several different pieces of information: the file name, the line number, the parent folder name (useful when looking at translation or configuration issues), and the project name: The Edit Options actions brings up the Lint Preference dialog, which has also been improved. You can now search through the options by filter: The options also let you enable all, disable all and restore to default which lets you quickly check just a single issue for example.
Finally, there are many new quickfixes for various issues, such as UseCompoundDrawable. |
|
