[Q] CLOSED: Android Studio -- Current Documentation? - Android Studio

I'm going through all the features of the current version of Android Studio (version 1.0.2) and am frustrated by the documentation. There is existing documentation at JetBrains, but much of it appears to be out of date. I've wasted a fair amount of time trying to follow some sections of documentation only to finally decide that they are simply incorrect; then, of course, I have to work through the system by trial-and-error.
My question is: Is there any comprehensive documentation for the current incarnation of Android Studio? The best I've found so far is the book, "Android Studio Development Essentials" by Neil Smyth. Even that, however, spends far more pages on Android development in general than on the Android Studio too.
As an example, take a look at https://www.jetbrains.com/idea/help/accessing-module-settings.html. The first step is to bring up the Project Structure dialog. That comes up fine, but appears to have been completely redone and the very next step, "click Modules", doesn't appear to be pertinent any longer. Furthermore, the "Modules page" that that should bring you to doesn't seem to exist any more (at least I couldn't find it anywhere). This (i.e., module) information seems to be retained in the app.iml file (the module is called "app"), but I don't see where it can be modified in the GUI.
I have a few questions about Android Studio (given the above), but will post them separately.
Thanks for any pointers .
Barry
-------------
UPDATE:
From IntelliJ Support:
Online documentation is for IDEA, not for Android Studio. Android Studio is a narrow tool for Android development, so it doesn't have all IDEA features.
Android Studio is based on IDEA core code, but it is developed by Google.
Closing this item out. (Although, not to put too fine a point on it, I still don't know where good/accurate/current documentation is for Android Studio (Google?).)

Related

Proper Gnu Tools ?

I'm just curious about something.
I recently moved from the iPhone to a Nexus One.
While I noticed there are a lot of ROM cookers etc (thanks for your great work guys) the development community seems kind of thin?
For example, on the iPhone there are full sets of all GNU tools. Anything you can use in Linux/Darwin they have for iPhone. There is a full apt packaging system will full console tools. The full OpenSSH suite has been made supporting all the wireless administration that I've come to love on my phone. Basically, it makes it feel like a full computer in my hand.
Now, I love this Nexus One, but I wasn't sure what the reasoning behind no one out there doing development on this kind of stuff. You'd think a phone running Linux with all code available would attract hordes of eager coders.
Instead we get weird crap like "dropbear" that has to be recompiled yourself to even work right, and even then...haha.
Not much as far as package management in the console, and our tools come from Busybox! Just seems very odd to me, but there must be reasons that I am not seeing.
This post is really not meant as an insult because I love this OS so far etc, but it just really suprised me that full sets of standard tools are not available.
Anyone know why?
Because you have to replicate the entire standard GNU/Linux userspace, which is a bear. Most of the work is done on the Android userspace instead, and you can find the fruits of those labors on AOSP Gerrit (http://r.android.com/) and the CyanogenMOD repository (http://github.com/cyanogen/android_vendor_cyanogen).
The best bet for getting a standard GNU/Linux userspace is to just boot Debian.
For future reference, this is probably not considered the correct forum for this discussion (probably Android General or the generic Android Development, not too sure.)
EDIT: Just to address some more specific points, Android has a package manager (those .apk files you see everywhere) and Busybox makes the most of the limited internal memory and provides enough tools to manage the Android userspace.
Sorry I thought the development forum would be the right place.
The iPhone 2g/3g have only 128mb of memory, and since gnu tools aren't resident in memory there is no problem having a full compliment of them on the phone.
The problem with debian is it is not really a nice UI for a phone. It would just be nice to have my phone, plus having the GNU tools underneath.
It isn't like its a dealbreaker, it just struck me as odd that all the proper tools have been built for the iPhone, and using it really feels like a full computer you're SSHing into, where as an open source Linux based OS on android basically is lacking all of it, minus the limited functionality provided by Busybox and Dropbear (like..dropbear really?).
These things have more memory and comparable processing speed to computers running windows 98 and early XP, so there is no reason not to have everything available to you when you need it.
I'm kind of a sideline commenter here as I'm not a coder, but it just struck me as odd.
Thanks for your reply!
anethema said:
Sorry I thought the development forum would be the right place.
Click to expand...
Click to collapse
NP, it's side discussion though. "Here's a complete set of native GNU tools" would be a dev forum topic.
anethema said:
The iPhone 2g/3g have only 128mb of memory, and since gnu tools aren't resident in memory there is no problem having a full compliment of them on the phone.
Click to expand...
Click to collapse
Nonono, not RAM. Flash memory. iPhone has tons of it. G1 (where most of the developers got started, mind you) has very little. Further, the partitioning left limited room for additional binaries. There's some ways around that (symlinks, mostly), but they aren't elegant, and are subject to wiping at inopportune times if you aren't careful.
anethema said:
The problem with debian is it is not really a nice UI for a phone. It would just be nice to have my phone, plus having the GNU tools underneath.
Click to expand...
Click to collapse
I'm curious about your use case. "It would be nice" is, well, nice, but is there a need you have that the existing tools aren't fulfilling?
anethema said:
It isn't like its a dealbreaker, it just struck me as odd that all the proper tools have been built for the iPhone, and using it really feels like a full computer you're SSHing into, where as an open source Linux based OS on android basically is lacking all of it, minus the limited functionality provided by Busybox and Dropbear (like..dropbear really?).
Click to expand...
Click to collapse
I'm not sure what's with the Dropbear hate. There are not many use-cases for SSH servers on a phone, so few people have worked on it. I'd think the Android-phone-powered robot guys are the most likely to need it. But again, Dropbear is going to perform a whole heck of a lot better on a G1 than OpenSSH, and the G1 is the origin of all this stuff.
Remember, Android is explicitly not GNU/Linux. You might call it "Android/Linux." The fact that the Android userspace is open-source means that the alternate (and exciting new) userspace is attracting development, instead of people trying to port GNU just so they can use their closed-source iPhone. This is, in fact, a Good Thing, because it can result in improvements for all Android users (via contributions to AOSP), not just that subset of geeks (read: us) who mod their phones.
Understanding this difference is key to understanding the development pattern. People aren't working on the GNU userspace for Android phones because the Android userspace supplants it. The tools we have do what is needed, nothing more. In fact, `am' and `pm' are more useful in the Android context than anything that's left out of Busybox.
anethema said:
These things have more memory and comparable processing speed to computers running windows 98 and early XP, so there is no reason not to have everything available to you when you need it.
Click to expand...
Click to collapse
Back to my use case comment above. What is it that you need?
anethema said:
Thanks for your reply!
Click to expand...
Click to collapse
No problem, it's a good discussion.
I guess it is basically that you don't know what you need until you need it. I treat my phones like this basically like little computers. Certainly on a laptop/desktop no one would bother questioning why you need general tools you use to get jobs done.
For the iPhone there was a need for unique certification to apples push servers so phones that were basically 'tricked' into activating could still get push messages via these servers.
I wrote a tool called Push Doctor with phone based scripts and with a donor style one server side. Basically I was generating these certificates and people could download them. The whole thing on both side is just a bunch of shell scripts. One running on the phone, one on my and cert donors computers. Now this may or may not have worked in busybox as I haven't tested it, but I just mean you never know what you are going to use stuff for, and having a nice standard set of tools across all Linux platforms can be nice to have for this reason.
As far as the space issue, I think that whole thing seems crazy as well. You're right there is a ton of space on the iPhone, but the G1 came out after it, and the Nexus One long after it, so its too bad 'space' is still an issue these days requiring ugly hacks to circumvent.
Regardless the tools could be distributed as part of several core apk's which people could install if they wish.
Like I said above, these are hardly embedded devices anymore. It's not like there's 4kb of ram and 5 mips CPU.
As far as dropbear, it isn't that I hate it, I just think even the G1 has comparable speed to the first iPhone (not in the Graphics/UI but certainly as far as the CPU is concerned) and running something as insignificant as OpenSSH should not be an issue. I've never personally heard of dropbear, and have no idea what their security track record is, but I do know OpenSSH's. It is a VERY widely used package with a lot of eyes on it making sure it is doing what it is supposed to be doing.
Apparently the default dropbear will authenticate any password if you enable passwords and you have to build your own from source run about 50 commands, all to get it going.
Where is the APK for a working dropbear, or apt-get install dropbear? Can you even have APK's for system level packages? Everything I seem to find tends to be a custom download from someones site whcih you have to 'push' to your phone, try to follow some 50 step guide to hopefully get going, etc.
I am loving a lot of facets of this OS, I'm just curious where the community is to work on this stuff, get it going, and make it easy. Android isn't really -that- young.
anethema said:
For the iPhone there was a need for unique certification to apples push servers so phones that were basically 'tricked' into activating could still get push messages via these servers.
I wrote a tool called Push Doctor with phone based scripts and with a donor style one server side. Basically I was generating these certificates and people could download them. The whole thing on both side is just a bunch of shell scripts. One running on the phone, one on my and cert donors computers. Now this may or may not have worked in busybox as I haven't tested it, but I just mean you never know what you are going to use stuff for, and having a nice standard set of tools across all Linux platforms can be nice to have for this reason.
Click to expand...
Click to collapse
Market Enabler is in that class of application, and, like other "rooted" apps relies on shell calls to Busybox on the backend--ugly, but keep in mind this is an attempt to explicitly defeat the Android security model. BB is sufficiently standard and POSIX conformant that it hasn't posed any difficulties for these kinds of applications.
anethema said:
Where is the APK for a working dropbear, or apt-get install dropbear? Can you even have APK's for system level packages? Everything I seem to find tends to be a custom download from someones site whcih you have to 'push' to your phone, try to follow some 50 step guide to hopefully get going, etc.
Click to expand...
Click to collapse
So-called "native"--that is, ARM binary--applications aren't supported by the Android platform in the conventional way. In mid-2009, Google released the Android NDK which permits ARM binary libraries to be intermingled with Android applications via JNI. Since Android is explicitly intended to be compile-once, run-anywhere (which is why apps run on a VM), this is only recommended for computation-heavy code. However, the Mozilla project is using the NDK to directly port legacy code (Firefox/Fennec) with a thin Java interface to the Android system, so such a thing is possible.
This doesn't really make sense for the GNU toolkit, though. The SSH case; you could certainly set up an SSH server to run as a system service using NDK+JNI to connect any SSH library you like. The fact that this has not happened leads me to believe that there is little demand.
In general, the needs of existing developers appear to be met by the tools available.
Based on everything you've mentioned--you may want to take a look at the Android Scripting Environment.

**Mandatory Naming Convention**

Might I suggest a naming convention for posts here ?
Currently we mostly have Windows Mobile, Windows Phone and Android devices on this forum. As this "Paid Software" forum is not split up into different OS's (yet ?) we should have a naming convention.
I am proposing the following scheme, including OS, version number, and root status.
Windows Mobile
[WM 6.x] <appname>
For WM apps that run on all WM 6 versions
[WM 6.5] <appname>
For WM apps specific to WM 6.5 (or 6.0, or 6.1, etc)
Windows Phone 7
[WP 7] <appname>
Any WP7 app
Android
[Android 1.6+] <appname>
For Android specific apps that require at least Android 1.6
[Android 1.6-2.1] <appname>
For Android specific apps that require at least Android 1.6, but are known not to work on for example 2.2 and 2.3
[Android 1.6+, ROOT] <appname>
Same as [Android 1.6+], but requires root.
Release dates, versions
Some apps include release dates and version numbers, suggesting that the date follow the OS specification, and version number follows appname.
For example:
[Android 1.6+, ROOT, 2010.12.31] MyRootApp v1.3 - The greatest app ever!
This is just all just a suggestion. Feel free to comment. I just think it should be easy to see these app sepecifics in the listing directly.
Chainfire said:
Might I suggest a naming convention for posts here ?
Currently we mostly have Windows Mobile, Windows Phone and Android devices on this forum. As this "Paid Software" forum is not split up into different OS's (yet ?) we should have a naming convention.
I am proposing the following scheme, including OS, version number, and root status.
Windows Mobile
[WM 6.x] <appname>
For WM apps that run on all WM 6 versions
[WM 6.5] <appname>
For WM apps specific to WM 6.5 (or 6.0, or 6.1, etc)
Windows Phone 7
[WP 7] <appname>
Any WP7 app
Android
[Android 1.6+] <appname>
For Android specific apps that require at least Android 1.6
[Android 1.6-2.1] <appname>
For Android specific apps that require at least Android 1.6, but are known not to work on for example 2.2 and 2.3
[Android 1.6+, ROOT] <appname>
Same as [Android 1.6+], but requires root.
Release dates, versions
Some apps include release dates and version numbers, suggesting that the date follow the OS specification, and version number follows appname.
For example:
[Android 1.6+, ROOT, 2010.12.31] MyRootApp v1.3 - The greatest app ever!
This is just all just a suggestion. Feel free to comment. I just think it should be easy to see these app sepecifics in the listing directly.
Click to expand...
Click to collapse
This is a great start, but what about apps that are linked to a specific type of phone?
For example, there a hardware specific apps for the Galaxy S line which includes Fascinate, Captivate, Vibrant, i9000, etc.
What I'm thinking, and feel free to offer a counter to this, is that most phones can be boiled down to a 3-4 letter identifier, which obviously includes the OS.
For example, Samsung Galaxy S series is SGS. So if I have an app for SGS I'd expect it to be:
[SGS 2.2+, ROOT]
Also in some cases there's specific features of ROM needed, for example with the SGS series again, backlight notification. I'd expect this to part of the list with ROOT.
Finally, I'd put version numbers and/or dates at the end of the post, in ()
So:
[SGS 2.1+ ROOT|BLN] My Cool App (v1.0)
[And 1.6] My Other App (01/15/11)
Any thoughts?
I think this sounds spot on. We definitely need a good naming convention given the broad scope of this new forum. Thanks much
Those are good suggestions.
However, it does require the average reader to know what all that means, it possibly makes it all too complicated.
Something like SGS could be an addition, but I think it should still simply start with the OS and version denominator.
For example:
[Android 1.6+, ROOT, SGS, BLN, 2010.12.31] My App v12
This is too long, I know. However date is most commonly in front on XDA. This should also clear up for the WM/WP users that this is not for them. An SGS user will still spot the "SGS" and know it is for them. Non-SGS users might have to read the thread to see that is is "For Samsung Galaxy S devices only!"
We need something better, but removing Android from the title isn't it, I think.
Wow seems really complex. The more it is complex the less it will be followed by OPs.
While I think it's a nice idea to open a section for paid applications I would have created it in all forums that already have an "Application etc." forum. It would sound more logical IMO and it would show OPs that they have to choose between the 2 subfora (development ongoing / paid applications for advertising only).
Creating juste one forum for all OS, devices etc. will make it difficult to find information in it and I don't think people will have the reflex to go in General forum to find applications.
If the application is in HD2 forum for example no need to have a long title people will know that the application is for HD2 only.
Just my 2 cents
You are absolutely right there, but paid apps are not allowed to be posted in the device-specific sections
Chainfire said:
Those are good suggestions.
However, it does require the average reader to know what all that means, it possibly makes it all too complicated.
Something like SGS could be an addition, but I think it should still simply start with the OS and version denominator.
For example:
[Android 1.6+, ROOT, SGS, BLN, 2010.12.31] My App v12
This is too long, I know. However date is most commonly in front on XDA. This should also clear up for the WM/WP users that this is not for them. An SGS user will still spot the "SGS" and know it is for them. Non-SGS users might have to read the thread to see that is is "For Samsung Galaxy S devices only!"
We need something better, but removing Android from the title isn't it, I think.
Click to expand...
Click to collapse
Hopefully proper sub-forums, as listed here will make the OS portion not needed.
Then phone types would make sense at the start, followed by OS version.
Finally, I was suggesting the date at the end more as a general style that would flow better. Just like for the most part, we go from least specific to most specific when identifying things (for example, Android 1.6) it would make sense that the name would come before any version or date specifier.
While I realize this would break with the tradition some user's have started, at best it is applied inconsistently so standardizing in a well known and defined way seems like a good thing.
It seems indeed they are coming.
Let us then, for the few days we still have to wait, use the suggested format of simply adding the OS name and version in front of the release ?
Chainfire said:
It seems indeed they are coming.
Let us then, for the few days we still have to wait, use the suggested format of simply adding the OS name and version in front of the release ?
Click to expand...
Click to collapse
That seems more than fair.
People may want to hold off posting until the subforums show up, to keep the mods from having too big of a headache.
Great initiative Chainfire.
Once we have a reasonable naming convention, efforts will be required to ensure that it is adhered to.
We can set the App forums to require prefixes. Much like the optional "Is this a question?" adds [Q] at the start of a title.
NotATreoFan said:
We can set the App forums to require prefixes. Much like the optional "Is this a question?" adds [Q] at the start of a title.
Click to expand...
Click to collapse
Yeah I think we should.
We'll let the committee decide on final subject format, and then have it implemented, I guess.
Good idea.
there should be a set of prefixes to choose from, at the beginning of the "create thread title" in "create new post".
you can only use from standard list and no [ ] allowed in titles, custom prefixes with { }
XDA admins would also need to run script on thread titles to replace ALL current [ ] with { } for all prefixes not in list previously mentioned.
not terribly hard, would help a bunch.
nice nice nice

[Q] Making My Phone Compile Itself: JDK vs Apache Ant, other questions

I'm undertaking a stupid project and would like to ask some questions of some more experienced developers. Yes I know there's no practical reason for this, and no you cannot talk me out of it.
I would like to create a sort of "super nerd" adaptation of CyanogenMod for command line Linux junkies, or at least for Comp Sci grad students like myself. I want my phone to be able to recompile and reinstall nearly everything it runs. Yes I know that's a painful and slow operation: I did "emerge tightvnc" on a chroot Gentoo install and the command took about 18 hours. I remain undeterred.
Questions:
Sun JDK is apparently not available for arm7a. Am I reading the docs correctly, and one can indeed use Apache Ant to compile Android? Or is Ant not what I think it is? I'm not opposed to creating a small Bochs VM that boots, mounts a network filesystem, executes some JDK task, and then signals to terminate. I'd rather not if I can help it though.
How much access does the radio hardware get to the rest of the system? If I were to store something personal in an encrypted loopback partition, could someone abuse direct memory access to read from memory without the host OS knowing about it?
Has anyone played with adapting the Android boot process to use System V type init scripts? I'd like to make it easy for Tasker to say "we're running out of memory -- go from init level 5 to something arbitrary, say 7, which stops some services. Oops, still low, go init level 8, which disables more services.
I definitely plan on sharing my work. What do you guys think of the name CyanoGentoo?
Thanks all.
Apparently Apache Ant is not what I thought it is.
How about this then: does anyone know where I might find a community for people interested in general purpose computing on an Android phone?
Michael Spencer said:
Apparently Apache Ant is not what I thought it is.
How about this then: does anyone know where I might find a community for people interested in general purpose computing on an Android phone?
Click to expand...
Click to collapse
Don't know if you're still around but I'm very interested in helping and believe I may already have some solutions for you. If you're still running chroot or another form of ARM Linux distro (Debian based is what I'm coding for at the moment) then check my github
https://github.com/S0AndS0/Debian-Kit-Mods
The readme file has directions on how to clone and run the main modding script which curently has at least one if not two options that'll peek your interest for sure.
One set of options will download and install Java's JDK (either hard float or soft float) and another will download and install jMonkey (a user friendly programing SDK built on eclips) which will get you one step closer to compiling things on an Android device for Android devices. However, I've yet to crack running "Android SDK" because they have yet to reliece an ARM compatible source and "wine" (a Linux package for emulating other CPU's) is still under heavy development, so building Android from source and such is still out of the scope of what I've been able to script up for easy use.
On a side note; a quick google search of my user name and the key words guide, linux, jdk, arm and xda will result in links of what I've written up on enteracting with Linux on Android if you get stuck anywhere.
And if you search "raspberry pi android adb similar:xda" you'll find what I'll likely be working on bringing to Android; after debugging the script I'm working on to set up a Brendle (one of many methods of "cloud computing" availible for ARM) node/network through all availible network interfaces (bluetooth, 3G/4G, wifi) on Android.
Sent from my SPH-D700 using xda app-developers app
I am still around, and when I get a chance I'll take a look. I think I'm mostly satisfied with AIDE and chroot Ubuntu.
And those worried about dma exploits via radio hardware need only use a wifi-only device with a portable hotspot, I've concluded. No way to prevent these exploits otherwise.
Thanks again.
Michael Spencer said:
I am still around, and when I get a chance I'll take a look. I think I'm mostly satisfied with AIDE and chroot Ubuntu.
And those worried about dma exploits via radio hardware need only use a wifi-only device with a portable hotspot, I've concluded. No way to prevent these exploits otherwise.
Thanks again.
Click to expand...
Click to collapse
Indeed AIDE has been a fantastic tool for me as well.
Heh dma was indeed a concern of mine among other security issues with running Linux over 3/4G but its to bad there's no solution yet. I'm using old phones and tablets for most tests but try as I might I can't break into them from out side my hotspot network... even though I can connect to the divice running the hotspot remotely if it is running Linux too.
hmm, I'm working on a new script of examples for networking now, lots of building blocks to my latest project, which may help new scripters with some networking tedium of finding and assigning specific IP's to variables so they can be shared or saved or modified into other commands quickly. This will upon compleation will be one of the references for other scripts I'm working on for getting openstack and MPI running on multiple devices swiftly.
Speaking of MPI; the installer for Bramble on Android now works (install option 2 within for Debian Kit users) for getting that software package installed and all that is left to work on is the setup for machine files and sshkeys for multi-node quick set-up.
Two questions; seeing as how you have AIDE, perhaps you might be able to help with my other project that I'm working on? I've another github repo where I'm working to incorporate a; soft/hard float Linux installer, terminal emulator, rdp/vnc client, scripter, and forwarding of Linux GUI to a second device and/or Chromecast of a specific desktop or Linux window with x11... Currently stuck on the terminal but still very new to Java for Android.
or because that's a bit much to ask; perhaps some help with Android scripting for installing Linux on Android that uses Debian Kit's methods to provide hard float or soft float?
I'll be around and have modified my sig for easier tracking and will be pushing more updates to github today, hopefully by the end of the day have a sshkey passer script for quickly setting up passwordless remote login. After that will be some work on setting up bridges between USB, Bluetooth, Wifi, and any other network interface available for faster transfer of large data sets.
Edit 03192014
Michael Spencer said:
Has anyone played with adapting the Android boot process to use System V type init scripts? I'd like to make it easy for Tasker to say "we're running out of memory -- go from init level 5 to something arbitrary, say 7, which stops some services. Oops, still low, go init level 8, which disables more services.
Click to expand...
Click to collapse
Check out the Debian Kit app, from what I have found it exposes all of the Linux processes and file system to Android and if running as root user on Linux then the full Android file system is exposed too. Debian Kit doesn't use chroot to run Linux so it's "possible" to run a chroot environment at the same time. And running "ps" commands on Android or Linux terminals, produce nearly identical output, of both Linux and Android processes happily running meaning that if Tasker can't see these processes then a script can run the "ps" command and run a command to shut down Linux processes; likely it's a bit more complex because re-starting those services or even suspending some could cause un-wanted behavior. Still though with testing and time it is possible to have the memory better managed.
Update 03312014- Back on making your phone compile itself subject; I'm working on using(/scripting an installer for) OpenStack on Android, which has QEMU for emulating CPU processors which will eventually allow us to install Android SDK on Android(s) running Linux. I'm using OpenStack because to emulate a normal PC processor one even a quad core ARM processor is really slow (use to be an app for this called Limbo PC emulator but last I searched the market place this app was gone) so using OpenStack will allow us to throw what ever extra Android phones into a pool of sharable CPU power; essentially I'll be creating a 7 or 8 (virtual) core processor out of networked Android phones and then emulate a 2 or 4 core x86 processor within and install the tool kits for android that have CPU requirements.
I've other plans for OpenStack too but those will require that I incorporate mesh networking and google translate. So that users anywhere can build a cloud of shared processing power.
Sent from: SPH-D700 or myTouch3Gs or Sero 7 Pro
Linux Install guide for Android devices that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
Or
https://docs.google.com/document/d/1ssVeIhdBuuy8CtpBP1lWgUkG6fR6oHxP20ToYPPw6zI/edit?usp=drive_web
And my script pack for installing; Java's JDK, node.js and more to your Linux OS
https://github.com/S0AndS0/Debian-Kit-Mods
Note: if you're new to Linux/scripting/command line; check readme file for instructions.
http://www.timelesssky.com/blog/building-android-sdk-build-tools-aapt-for-debian-arm
http://www.timelesssky.com/blog/develop-app-on-android-with-android-sdk
Hey all found the ^answer^ if you've not already found this blog then you all are in for a treat dig around on that above site and you'll find some other really cool stuff for Linux Android systems.
Sent from: SPH-D700 or myTouch3Gs or Sero 7 Pro
Linux Install guide for Android devices that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
Or
https://docs.google.com/document/d/1ssVeIhdBuuy8CtpBP1lWgUkG6fR6oHxP20ToYPPw6zI/edit?usp=drive_web
And my script pack for installing; Java's JDK, node.js and more to your Linux OS
https://github.com/S0AndS0/Debian-Kit-Mods
Note: if you're new to Linux/scripting/command line; check readme file for instructions.

[Q] CLOSED: Configuring / Editing Modules

I'm trying to understand modules in Android Studio 1.0.2. How they are configured, edited and stored.
It's easy enough to create a new module (File->New Module) and the information gets stored in the module's iml file (e.g., app.iml).
However the documentation regarding about editing a module (https://www.jetbrains.com/idea/help/modules.html) seem to be out-of-date and I don't understand if/how facets are used (and/or are applied).
Can modules be edited in the UI?
Are facets still used in this version of Android Studio (1.0.2) and, if so, how are they viewed/edited?
I'm new to Android Studio so that may be part of the problem -- e.g., I'm not familiar with modules and facets in the earlier implementations.
Thanks!
Barry
-----------
Update:
-----------
From IntelliJ Support:
This description is for IDEA projects. AS doesn't have facet (it uses only one facet - Android).
Android Studio is based on IDEA core code, but it is developed by Google.
I'm still not sure how modules may or may not be pertinent for Android Studio, but apparently facets aren't (other in the degenerate case mentioned above) and it doesn't appear that there is any current documentation that is specific to Android Studio (at least, not yet -- hopefully Google is working on some (?!)).
Closing this out.

Start Activity on Android Auto's Desktop Head Unit

Hi, I have searched the forum to find an answer to this question, and I understand it is probably a basic question, but I appreciate anyone's ideas.
I am trying to start an activity in my app and view it on the desktop head unit. I can easily use the startActivity() method to see the activity open on my Android tablet. However, I don't know how to start an activity so it appears on the head unit instead. I have tried many approaches, including starting a service, but nothing has worked. Thanks for your suggestions.
Android and Android Auto is a complete different world. You always need SDKs to program for a specific platform. For Android Auto this is not available, so with any basic Android tutorial you cant reach anything. If you have a Head Unit (from China) with basic Android you can for sure program it like any other Android device. But if you want to use the Android Auto environment build in many new cars, I tell you its more than hard for you to get anything running. Only way you can program right now is a Messaging or Music playing app. So the possibilities are quite limited. More information under https://developer.android.com/training/auto/index.html

Categories

Resources