IssueTracker

Thank you very much for reporting this issue, Jack. Looks like the issue is caused by somewhat unnecessary and contrived logic in apksigner.bat, which is special-casing -J* parameters. Unfortunately, this logic doesn't handle whitespace containing parameters, even those which aren't -J*.

I've uploaded a tentative fix https://android-review.googlesource.com/#/c/394238/ for review. The patched apksigner.bat is attached. This fixes the issue on my Windows 10 box.

Jack, please test the fix in your environment and let us know whether it works for you too.

Confirmed, that fix works. Thank you for the quick turn-around on this.

Project: platform/tools/apksig
Branch: master

commit b293b2087837853e32a1cff008d58644dbbd4cc2
Author: Alex Klyubin <klyubin@google.com>
Date:   Wed May 10 16:53:25 2017

    Handle whitespace when removing -J* parameters in .bat
   
    apksigner.bat contains special logic for -J* parameters. This logic
    was not designed to handle parameters containing whitespace. This
    commit fixes the issue. It is unclear whether this -J* logic is even
    needed. So, if it keeps breaking stuff, we should probably simply
    remove it.
   
    Test: apksigner sign --ks "nonexistent.jks" --ks-pass pass:123123 --ks-key-alias "bug apksigner test" nonexistent.apk
          Fails with FileNotFoundException instead of "a was unexpected at this time"
    Bug: 38132450
   
    Change-Id: Ice3294e9993b075533c77d94eb870cfd35a65bbc

M       etc/apksigner.bat

https://android-review.googlesource.com/394238
https://goto.google.com/android-sha1/b293b2087837853e32a1cff008d58644dbbd4cc2

Project: platform/tools/apksig
Branch: master

commit 0f88b97634034673f062a8ac6c3dab7d3d9befe3
Author: Alex Klyubin <klyubin@google.com>
Date:   Thu Jun 22 09:43:22 2017

    Bump apksigner version to 0.7
   
    Changes since 0.6:
    * Fixed a bug in whitespace handling in command-line parameters in
      apksigner.bat. https://issuetracker.google.com/issues/38132450
    * Fixed a bug in JAR signature verification when multiple digests
      are present for the same named entry in MANIFEST.MF.
      https://issuetracker.google.com/issues/38497270
    * Honor android:targetSandboxVersion (introduced in Android O) when
      verifying APKs. When android:targetSandboxVersion is set to 2 or
      higher, the APK is required to be signed with APK Signature Scheme
      v2.
    * When signing, reject APKs with CR, LF or NUL in ZIP entry names.
      Such names are not permitted by the JAR siging spec and are also
      rejected by Android Package Manager.
   
    Test: apksigner version
    Bug: 38132450
    Bug: 38497270
    Bug: 36426653
    Bug: 62211230
    Change-Id: Ifa120b0e43b458c99c3da6fde1136e0cbb92caee

M       src/apksigner/java/com/android/apksigner/ApkSignerTool.java

https://android-review.googlesource.com/420784
https://goto.google.com/android-sha1/0f88b97634034673f062a8ac6c3dab7d3d9befe3

The fix has been released in apksigner 0.7, released as part of Android SDK Build Tools 26.0.1.

While I agree that the performance is abysmal, there is no need to lock up the UI.

A layout including a progress bar and scrollview:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/layoutView" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical">
    <ProgressBar android:id="@+id/progressBar" android:layout_width="match_parent" android:layout_height="wrap_content" style="@style/progressBar" />
    <ScrollView android:id="@+id/scrollView" android:layout_width="match_parent" android:layout_height="match_parent" android:fadeScrollbars="false" android:paddingTop="8dp">
        <TextView android:id="@+id/textMessage" android:layout_height="wrap_content" android:layout_width="match_parent" style="@style/labelTerms" android:paddingLeft="16dp" android:paddingRight="16dp" />
        </ScrollView>
</LinearLayout>


where txtMessage = the TextView, and progressBar = the ProgressBar:

new ReadGPSTask(getActivity(), txtMessage, progressBar).execute();


//-------------------------------------------------------------------------
// AsyncTask Read Google Play Services
//-------------------------------------------------------------------------
       
private class ReadGPSTask extends AsyncTask<Void, Integer, Void>
{
 Activity activity;
 TextView textView;
 ProgressBar progressBar;
 StringBuilder bufferEula = null;
               
 public ReadGPSTask (Activity a, TextView tv, ProgressBar pb)
 {
        activity = a;
        textView = tv;
        progressBar = pb;
 }
       
 @Override
 protected void onPreExecute()
 {
        progressBar.setVisibility(View.VISIBLE);
        textView.setText(activity.getResources().getString(R.string.loading));
        return;
 }
       
 @Override
 protected Void doInBackground(Void... params)
 {
   try
   {
        bufferEula = new StringBuilder();
        publishProgress(20);

        // Google Play Services attribution
        try
        {
         switch (GooglePlayServicesUtil.isGooglePlayServicesAvailable(activity))
         {
          case ConnectionResult.SUCCESS:
          case ConnectionResult.SERVICE_VERSION_UPDATE_REQUIRED:
          case ConnectionResult.SERVICE_DISABLED:
                               
           bufferEula.append(GoogleApiAvailability.getInstance().getOpenSourceSoftwareLicenseInfo(activity));
           break;
         }                      
        }
        catch (Exception e)
        {
        }

       }
       catch (Exception e)
       {
       }
       finally
       {
       }
               
       return(null);
 }
               
 @Override
 protected void onPostExecute (Void result)
 {
   progressBar.setVisibility(View.GONE);
   textView.setText(bufferEula);
 }
               
 @Override
 protected void onProgressUpdate(Integer... progress)
 {
  progressBar.setProgress (progress[0]);
 }
}

this gives the user a progress bar while loading the content.  Of course this would be even better if the content loads much quicker!

Google, will there be any updates to this issue?  Client QA complains periodically about how slow this call is, but I really don't want to waste their time and money putting in a workaround for a bloated legal String request, especially when this issue can be fixed at source at any time, without requiring a new build from us.

Please do some simple text editing here.  Make the result returned from getOpenSourceSoftwareLicenseInfo() a maximum of few kilobytes, with a summary of the legal attributions, and then provide a link referring people to the full text elsewhere online.

Thanks for the reports of this issue. Good news. Users can now see all of the license information for Google Play Services by going to Android Settings > Google > Overflow menu > Open Source Licenses on their device. Since that is the case we have removed the attribution requirements for developers using the Google Maps Android API. You no longer have to call GoogleApiAvailability.getInstance().getOpenSourceSoftwareLicenseInfo() and show that text in your app.

Thanks for the info. In that case shouldn't GoogleApiAvailability.getInstance().getOpenSourceSoftwareLicenseInfo() become deprecated? Or at least mention fact that call is no longer required in API reference. That would be great to have this stated clearly.

Yes, the method will become deprecated in an upcoming release of Google Play Services, at which point the API reference will be updated accordingly.

In the meantime, we have removed the instructions to call this method from our Guides on developers.google.com/maps/documentation/android-api/.

The getOpenSourceSoftwareLicenseInfo() method in the GoogleApiAvailability class is now deprecated in Google Play Services 11.0.0.
See the updated reference doc here:
https://developers.google.com/android/reference/com/google/android/gms/common/GoogleApiAvailability.html#getOpenSourceSoftwareLicenseInfo(android.content.Context)

> we have removed the attribution requirements for developers using the Google Maps Android API

Please can you confirm there are also no attribution requirements for developers using other Google Play Services features (e.g. analytics)?

That is correct Mark. The attribution requirements have been removed for the entirety of Googly Play Services.