It heavily depends on what kind of syncing you need.
If your app is a news app that publishes posts at a certain time every day(lets say at 7.45 AM every day), then you run a periodic task in a background service, say at 8 AM.
e.g.: Drippler. They notify me once every day(around 6.30 PM). I believe they use a periodic task.
If your data transfer is triggered by user action, then use a background service or an AsyncTask for the data transfer.
e.g.: DropBox/Evernote. They sync when I interact with the app.
If your app runs instant messaging/mails/non-periodic important updates, then you need push notifications, because you want to alert the user immediately. Use either GCM or Parse for this case. e.g: WhatsApp/Google chat. Since you explicitly mentioned you don't want to use GCM, I will tell why you should use a standard push notification provider instead of writing your own:
Push notifications work instantaneously - there is very little delay(in the order of seconds, rarely minutes). If you were to implement your own solution/library for doing this - in a naive model, you would ping the server every second or 5 seconds or a minute to check for the status. This is very inefficient as it consumes CPU(and hence battery), bandwidth on the mobile and load on your server. However, in GCM/Parse, they always keep a port open with the server(see here). This is the standard and most efficient way. Plus, if 10 apps use GCM, you don't need 10 open connections, you only need one per device. And you really don't want to develop your own solution unless you have a valid reason/funds/time to do so.
A note on Sync Adapter: Sync Adapter works well for all the above three cases. Check Running a Sync Adapter and you will see that it either depends on GCM or your own mechanism(event trigger or custom solution) or network availability(event trigger) or periodic event. All in all, this is a good convenient class for syncing data without having to do a long list of initializations every time or to implement all the above cases at one place.