[MacPorts] #31826: android: whitespace cleanup and update to sdk15 + features

[MacPorts]

#31826: android: whitespace cleanup and update to sdk15 + features
----------------------------------+-----------------------------------------
 Reporter:  ecronin@…             |       Owner:  krischik@…           
     Type:  update                |      Status:  new                  
 Priority:  Normal                |   Milestone:                       
Component:  ports                 |     Version:  2.0.3                
 Keywords:  haspatch              |        Port:  android              
----------------------------------+-----------------------------------------

Comment(by ecronin@…):

 Portfile is still half tabs half spaces and doesn't match the modeline.

 The port still installs the bare minimum amount of the actual Android SDK
 in a way that's managed by MacPorts, and then the user has to run the java
 gui installer to install various packages into MacPorts' directory
 hierarchy, which MacPorts then knows nothing about.  There was a mailing
 list thread not long ago about a user accidentally blowing away some of
 their VMs because the upgrade often requires you to force activate because
 of all these untracked files and they instead went in and rm -rf'd them.

 The only thing the current port gives a user over them installing the SDK
 themselves in their homedir the way the Android docs describe is some
 double-clickable wrappers in /Applications/MacPorts.  What it doesn't give
 is a quick way to get the command line tools to talk to an android device
 which is all I really care about.  If you're doing serious android
 development you're better off not having your SDK hierarchy under
 MacPorts' (or any package manager's) control in any way from what I've
 seen.

 I guess I only implied it in the report, but I have no time to maintain
 something this complex and I don't actually do app development where I use
 the full SDK and simulators.  I just never upgrade the port and
 ${prefix}/bin/adb still works for what I need.

 If the maintainer isn't willing to go all the way to support macports
 managing everything and without the need to make things under ${prefix}
 group-writable so packages can be installed there directly I think a
 better approach would be for the .app wrappers look/ask for a SDK
 somewhere outside of the MacPorts and that be all that is installed by
 this port...  If they do use the routine to fetch and install packages
 from Google's manifests subports are a far better idea than all the
 variants I had in that old patch

-- 
Ticket URL: <https://trac.macports.org/ticket/31826#comment:2>
MacPorts <http://www.macports.org/>
Ports system for Mac OS